Re: Talk about other OSes(was: Functional programming)

On 7 September 2015 at 14:37, Sergio Tortosa Benedito
<[email protected]> wrote:

> Yes, however, for me the main reason against those OSes are drivers.

Again, it varies from person to person.

If it's all about drivers, then everyone would run Windows.

I'm typing on an old Thinkpad X200s. Everything worked out of the box
with Ubuntu 13.10: sound, wifi, suspend/resume. There were glitches in
the graphics, though. 14.04 fixed that, so I've stayed with it.

What really surprised me is that getting the fingerprint reader
working was trivially easy. I didn't expect that.

I was also a little surprised that I had to do extra work to get
scrolling working with the Trackpoint -- I thought that should work
out of the box. But then, on my other laptop, a Toshiba Satellite Pro
P300, I had to do extra work to enable trackpad scrolling on Windows 7
-- the Windows drivers did not support it.

For some people, if it boots and runs that's enough. I know people who
refuse to use Wifi, and USB, and Bluetooth. I used to use infra-red
heavily, which most people never wanted.

It varies.

Generally, if you can install it, you can probably get most hardware
working with some effort, from Linux to FreeBSD to NetBSD. But, for
instance, if your OS does not support Wifi (as some I have used do not
-- e.g. MorphOS, AROS) or USB (Windows NT 4) then it might be
/easier./

> While awesome, won't this hurt performance?

Not if it is done right, no. All modern CPUs are relatively similar.


> I'm not very fond of the JVM,
> and yet it's the fastest one pretty much

Maybe today. It is very poor and primitive compared to the systems of the past.

There was an OS in the 1980s with total platform transparency -- I saw
a demo of it running on an Acorn RISC PC with both an ARM CPU and a
486. It was using both CPUs transparently.

It was called Taos, from Tao Group, later renamed Elate from Intent.
It translated on-disk binaries into the CPU's instruction set as part
of the process of loading them from disk into RAM: in other words it
postponed the very final part of compilation until loading the file
from disk. Any binary, the whole OS included, could run on any
supported CPU, and it ran on about 6 different CPU architectures (x86,
ARM, PowerPC, MIPS, etc.) which were all totally incompatible.

It was very, very fast. There was no slowdown.

Intent was nearly the basis of a next-generation Amiga operating
system but the deal fell through. Development systems were shipped
though.

The whole concept that "source code" must be "compiled" into a "native
binary" is an artefact of the Unix family of OS design. IBM's AS/400
doesn't do that -- now sold as an operating system for IBM System P
servers, what used to be called RS/6000 with POWER CPUs.

My main area of research recently is Lisp Machines. These were
high-end workstations from the 1980s, killed off by cheaper Unix
computers, which ran the high-level language Lisp on the CPU. The
whole OS was shipped as source code; the CPU ran source code
more-or-less directly. No compilers, no object code, no linking, no
binaries. The whole multitasking, Internet-capable, GUI OS running
Lisp code directly. It wasn't "source" as it never turned into
anything else. There was no "destination."

Think of 1980s home computers with BASIC in ROM... but imagine that on
top of BASIC was a whole rich multitasking OS with a window system and
everything. No compilers anyway.

Unfortunately for us all, the C family won and as a result we are
stuck with a model of programming intended for low-performance 1960s
minicomputers.

> (but is quite bad in regards to
> RAM).

Not a big problem today, though.

>  I think it would be possible to implement this in Linux by serializing
> the process memory (of course without the VM part).

I think for good results it needs to be a part of the core design, not
bolted-on later.

> If you are willing ti answer I have two more questions: have you toyed with
> microkernels?

Sort of. I have a test VM with Minix 3 in it. That's the leading
open-source microkernel Unix today. But it's still immature -- version
3 was a total rewrite.

> How big is their performance impact?

Overstated. My main phone is a Blackberry Passport. Its Blackberry 10
OS is based on QNX.

QNX is a real-time microkernel OS developed in the 1980s -- it's older
than Linux or FOSS BSD. It's SMP aware and very fast. A famed demo
version ran a whole GUI, desktop, web browser and TCP/IP stack from a
*single 1.4MB floppy*.

Microkernels can be very fast.

The developers of Plan 9 claim that its design makes the whole
macrokernel/microkernel question moot: Plan 9 is neither, they say. I
do not know enough about it to judge.

Mac OS X is not a true microkernel, as embedded into the Mach 3.0
kernel is much of the FreeBSD kernel, the "unix server". So it's not
"micro" any more. It is fast, stable and widely-used though. It's the
most successful commercial Unix of all time.

So, yes, they work. But if you step outside the C programming model of
static binaries talking to each other through libraries, then the
whole question of microkernels goes away -- it is really only an
artifact of the C way of building OSes, which includes all forms of
Unix and all forms of Windows too. The classic MacOS (MacOS 9 and
earlier) was originally written in a mixture of assembly language and
Pascal, so it was outside this family -- but it is dead and gone now.

>  and is really beneficial
> that view of  everythins is a file?

Well, that is part of the Unix way of designing and using an OS. If
you look at non-Unix OSes, no, nothing else works like that. But Unix
doesn't take the idea all the way -- the snag is that Unix caught on
and got big, successful and complex before the idea was completely
finished and executed, so the later OSes that are truer to the mantra
of "everything is a file" were sidelined.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: [email protected] • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: [email protected] • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
_______________________________________________
gobolinux-users mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-users