New development release - 1.64-dev1

[winston]

If you've not already got it via the nightly build, there is an official package now which is the Linux version of the release that aegidian just announced. You can get it at the usual places:

http://oolite-linux.berlios.de
ftp://ftp.alioth.net/oolite
rsync://rsync.alioth.net/oolite/dev/Linux-x86

(Rsync users please note the new URL! This is preparatory to an update to oolute-update which will work for stable, development and nightly builds, and a new rsync repo structure that will work for all platforms).

The changelog - see Aegidian's announcement in 'Testing and Bug Reports' for the 1.64 version.

VOLUNTEERS WANTED: If you're brave, please download the Autopackage or binary tarball - this build was *not* built on my usual machine, but rather built on vexed3.alioth.net - the server that does the nightly builds. I'm trying to move off doing official builds on my computer because I have to wait about an hour while the builds upload to alioth.net through my pathetic 256kbit/s ADSL upstream. Building on vexed3 means that there is no network transfer to the rsync or ftp site - it's on the same host. Also, when uploading to berlios, I'm uploading with a 10Mbit/s internet connection. But vexed3.alioth.net is quite a bit different from my desktop PC - it runs Debian stable rather than Fedora Core, and I think the OpenGL dev libs are different too -- but my testing so far indicates that it runs exactly the same as the builds from my desktop system.

[celkins]

Would it be too much of a pain for you to make src & data tarballs available, as you've done previously?

My reason for asking is that, to date, building new FreeBSD versions within the port skeleton has just been a matter of downloading the new tarballs, and updating the distinfo & Makefiles for the new version : it's far more of a pain to try using someone's binary distro due to library differences.

Thanks.

[winston]

I would have, except I'd not updated 'mksrctarballs' since the change to GUSTO (I actually made the update last night). Tonight I'm going to use that script + test a rather vile Perl script I wrote to take out the pain of updating berlios.de so the source tarball release should show up.

If you regularly track the source, then Subversion is probably better than the source tarballs.

[Spooky]

Celkins, you mean updating the Makefile and Distinfo in the ports tree right? If you can put those changes somewhere where people can easily find them and they are well documented then I'll happilly stop making FreeBSD binaries.

[celkins]

Winston: PERL script - 'rather vile'... just remember, "there's more than one way to do it"... VILE is VB script, which I've had the misfortune to try to use at work...

Spooky: that's right - my only issue with your binaries is the classic 'binary distro' problem of library versions; the main issue I see is that, as a non-committer, there's a potentially long lead between me making it work, and it appearing in 'ports' if I "do the right thing" ie submit a PR. I'd be only too happy to make the changes available to others, but my own website is on the wrong side of an ADSL link (well, asymetric cable, anyhow) - any suggestions as to how best to do this?

[winston]

Oh, I agree on VBScript - it is the spawn of Satan himself. However, the vileness of the berlios updater is more of a reflection of the vileness of the HTML that berlios spits out

[Spooky]

Celkins,

You might want to check with Winston but I think the wiki is the perfect place.

http://wiki.alioth.net

Now I feel the need to explain my tarball making decision.

1) I know the library compatability is a bitch but the tarball is totally self contained (provided you run the FreeBSD adjusted version of Winston's execution script before hand) and if you only install it for your user then there really should be no intereference.

2) Personally I don't like the ports version of SDL at all, and GNUstep is a bitch at the best of times.

3) The main reason for the binaries is that a few of my users have BSD machines and wouldn't know one end of a ports from an another It made sense to share work I had already done.

Just as a passing shot, I don't suppose you spend anytime with NetBSD do you? I'm having a serious problem with p-thread semaphores on NetBSD 3.0 i386 when trying to build. It's a long shot but you seem like a *BSD guy.

[celkins]

Your explaination makes a lot of sense, and it's good of you to share what you've done.

I'll see what I can do re using the Wiki for sharing my small efforts.

Never did much with NetBSD - so I probably can't help, but I do remember the comments that the engineers who were in my team at Pace made about the Linux p-thread implemetation having certain brain-dead 'features' when they had to use it - there are certain fundamental 'short comings' in p-thread semaphores, like atomic creation & initialisation of a semaphore

... RISCOS was far better

Drop me a line by email, and I'll see if I can help at all - my spamassassin is well trained, so I'm not too bothered about including this mailto:[email protected]

[winston]

Well, apart from RiscOS being co-operative multitasking (a bad idea on all levels), and lacking any kind of virtual memory protection (Although to be fair, the hardware that RiscOS started on wasn't really capable of much more - but what's bad is that it hasn't been updated, and even the recent versions of RiscOS can't even be considered to be a modern operating system)

[celkins]

At an application level, you're technically correct, but well written applications in a cooperative MT environment often result in the delivery of a better end-user experience, since the app that you're interacting with typically can get more CPU time, since it'll be receiving more events. As you said, the hardware we used was 'limited' - it's certainly not fair to compare a 40Mhz ARM7500FE with 16MB EDO RAM to a 1GHz+ PentiumIII class processor with 1GB+ DDRII RAM and expect it to do the same, but just look at what we did deliver on this back in 1997/8(ish) (A7000/A7000+) - ISTR PCs were not quite as usable back then...

RISCOS didn't support VM for 'marketing reasons' - they wouldn't guarantee to have a HDD in all systems : RISCOS had task swapping code from very early on, it just wasn't enabled. Heck, it was hard enough for me to persuade the product marketing group that selling a discless machine with less than 4MB RAM was a bad idea, but I managed it in the end (well, they agreed to let it be permanently 'out of stock', anyhow).

If you only look at multitasking at the application level, too, you neglect much of what's actually going on 'under the hood' - taking the STB version of RISCOS (the last that I worked on, up to 2004), the application level multitasking represented pretty much just the icing on the cake - there was often only Fresco running as an app, but the IP stack, video server controller, video/audio demux & decode (largely in software) et al were all multitasking away, running on a callout & callback model, and doing a damned good job, especially when you consider the limited hardware - 40HMz ARM7500FE & 32MB RAM. Don't make the mistake of dismissing this as 'all interrupt routine stuff' either, it wasn't.

As for updating it - on the day we first got the RISCOS desktop running on the real Pheobe hardware (RISC PC II - a much more capable system), our then MD canned the project and began the closure of the Acorn Group... making a mint for himself in the process. What's happened since has been done by former developers (from the Acorn developer community - largely not actually ex-Acorn), and for a very small market, using a processor that is more often found in mobile phones, printers and network cards - they've not done too bad a job, really.


There, I feel better, now

[winston]

At an application level, you're technically correct, but well written applications in a cooperative MT environment often result in the delivery of a better end-user experience, since the app that you're interacting with typically can get more CPU time, since it'll be receiving more events.

But that requires programmers to be almost perfect all the time - in the real world, unfortunately this ideal state of affairs seldom happens and you wind up rebooting your machine because an application won't yield. This is why Windows 3.0/3.1 was so unstable, and why Mac OS <=9 was so unstable and why OS/2 - which did have pre-emptive multitasking but an extremely retarded single user interface input queue (meaning a hang in an application's UI meant the whole machine locked up even if the kernel and some services underneath continued to run) were such pains in the arse to use. The times I've used a RiscPC on RiscOS, I've experienced pretty much the same thing (although a RiscPC tends to boot quite fast!)

RISCOS didn't support VM for 'marketing reasons' - they wouldn't guarantee to have a HDD in all systems

You don't need a hard disk to have VM. Virtual memory just means that each process has its own virtual address space starting from address 0 and going to address 2^32 (or however many bits of address space the CPU supports). You do need things like an MMU (and I think many of the early ARM processors didn't have one, I'm pretty sure most of them have had an MMU for some time though). Even on a hard diskless machine, having virtual memory has several benefits:

- applications can't write over each other's address space (going back to my 'lack of perfect programmers' bit above)
- things like demand page loading can be implemented painlessly (and on a machine with limited memory, demand page loading is VERY useful)

My first Linux system was with kernel 0.11, and ran off two floppies. That had a VMM and demand page loading. This was in January 1992.

Don't make the mistake of dismissing this as 'all interrupt routine stuff' either, it wasn't.

Well, I'd say for your network card you'd want some interrupt routine stuff, it means your TCP/IP stack can sleep when nothing's going on and only woken when it gets an interrupt

I won't diss RiscOS for starting the way it did since it ran very well on extremely limited hardware. After all, it wasn't until around 2000 that Apple decided to go with this new-fangled pre-emptive multi tasking

[celkins]

Under RISCOS, each app was mapped in at 0x8000, running up to the top of current application memory (variable), and was the only *app* mapped at the time, the others being 'outside' of the memory map. The main problem area was the RMA, but when we tried write-protecting it, too much broke (mainly 3rd party stuff) - we'd planned to make RMA code area RO, and map RMA workspace RW : many other regions were protected against user-writes (and reads, in some cases). I'd have to check back as to the details of MMUs and which versions of OS were current etc..


Yes, the network card did use interrupts, and the service routine pretty much just flagged that there was work to do - in later versions of the stack, anyhow, earlier ones did much more in the service routine, and consequently showed the down-side to pre-emption, which this is, undeniably.


I'm impressed with your OS knowledge - put the porting task in good hands

Back to the topic in hand - do you support the idea of using the Wiki for me to share my bits on using the FreebSD port & tarballs, or do you have another preference? (BTW: offline now until Sunday evening).

[stevesims]

I used to be a RISC OS programmer - was a big fan way back in the day. There were some great things about it. I still miss not having a back button on my windows.

In retrospect RISC OS was a pretty poor, and very primative operating system. Yes, RISC OS was fast, responsive, and pretty stable most of the time, but a bad app could easily lock up the whole machine forcing a press of the reset button. No memory protection and a cooperative multi-tasking model weren't great choices.

RISC OS was clearly just Arthur version 2, and Arthur was clearly a rushed bodge job - in many respects an updated version of the BBC Micro OS (putting things incredibly simplistically).

Acorn had a great history of bad management, which eventually resulted in its demise. It's a shame that they didn't get in some decent project management for the ARX project - from what I have gathered that would have been an OS that did the ARM chip justice - instead we got Arthur, and the very slow death began.

(Yes - there's some great code in RISC OS - the font manager for example was a superb piece of work, and the Draw module was pretty good too.)

[JensAyton]

But that requires programmers to be almost perfect all the time - in the real world, unfortunately this ideal state of affairs seldom happens and you wind up rebooting your machine because an application won't yield. This is why Windows 3.0/3.1 was so unstable, and why Mac OS <=9 was so unstable[…]

Wrong. The old Mac OS’s instability was largely down to the lack of memory protection – it had a reliable and robust mechanism to exit a hung app since dawna time, but it tended to leave the system in a broken state.

After all, it wasn't until around 2000 that Apple decided to go with this new-fangled pre-emptive multi tasking :-)

Also wrong. Ever heard of Copland? Or PINK? 2000 is when they succeeded. :-)

[winston]

Oh yes, I heard of Copland and Pink, but like all vapourware, I can hardly consider it when making an OS comparison