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

El 7/9/2015 17:02, "Liam Proven" <[email protected]> escribió:
>
> 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.
Well, Linux it's on a good position and Ubuntu it's on the too, also
thinkpads are used in Linkx as they have pretty much the best support.

> 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.
Oh, with that no one would need interpreters anymore.

> 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.

Oh, I always thought all this OS X is a microkernel was FUD, but I see that
is true (not that is useful in this case).

> 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.

But if it is like this all around the world, eveb if this were an artifiact
(or a "bad" one at least) wouldn't peolpe tried to stop it, rather tan
continuing it.ç?

> >  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.

Given how much you have researched I'm sure you know it, but for me the
current next-gen OS is genode which solves some problems we are having
today in a extremely beautiful way, also they are aiming to be a
general-purpose OS.
> --
> 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

-- Best regards, Sergio

_______________________________________________
gobolinux-users mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-users