freenode/#sicl - IRC Chatlog
Search
4:49:13
beach
I have been reading a bit more about Genode. It looks like a fine system, and I am sure it could be used as a basis for some kind of LispOS. However, the philosophy seems very different from what I imagine with CLOSOS, and I don't think a CLOSOS-like system could be built on top of Genode.
4:51:17
beach
If I understand the documentation for Genode right, an individual component still has its own address space. A capability is very similar to a Unix file descriptor in that it is meaningless as a pointer, and requires the kernel to access the associated object.
4:52:30
beach
A remote procedure call is not a simple function call. It transits by the kernel, and the caller and the callee are in different protection domains, using different stacks, and even different threads.
4:53:22
beach
This organization is a requirement when application code has full access to its address space, as is the case with most traditional systems.
4:54:01
beach
CLOSOS, on the other hand, does not give an application access to its address space, so all applications share the same address space.
4:55:51
beach
Genode must require context switches to accomplish remote procedure calls, and context switches are expensive. In CLOSOS, there is no context switch, and the system is permanently in supervisor mode.
5:15:29
beach
As I write in some documents, I find it amusing that we still want people to program as if they have access to the bare machine.
5:16:40
beach
We present a model where each program lives in an address space that starts at address 0, that contains all its application objects, and especially its control stack.
5:17:39
beach
As long as we present such a model, we need to have context switches in order to prevent one program from destroying the data of another program, or of the system itself.
5:18:45
beach
And we need to have capabilities that are meaningless as pointers. In Unix, they are called file descriptors and they are just small integers that only the operating system knows what to do with.
5:23:26
beach
Chapter 3 of the Genode document shows capabilities as small integers. Furthermore, those integers are different in each component, and only the system can connect them to the corresponding objects.
5:24:14
beach
So, to summarize my impression of Gnode, I think the designers worked very hard to get a secure system, given that they wanted to preserve the traditional programming model.
8:26:29
MichaelRaskin
Genode fits how the modern CPU architectures expect you to balance safety and performance.
8:28:56
MichaelRaskin
Also, there is a lot of pretty bad code with no real good alternatives that you sometimes need to be compatible with (be it Web APIs, docx handling or WiFi drivers). And all the available documentation just lies outright. With Genode it is a reasonable amount of work to constraint this bad code and just run it.
8:30:10
MichaelRaskin
I guess CLOSOS could have some foreign containment areas to allow users choice in both of these problems…
9:19:26
beach
Such code would have the same disadvantages as code in a traditional operating system in that it would not be allowed to manipulate (references to) objects directly, and it would have its own address space.
9:20:29
beach
I guess one fundamental difference between Genode is that they want paying customers who can actually use it. I don't think I will have the energy to implement all the standards that are required in order to make CLOSOS practically useful.
9:33:21
beach
But Pike wrote that they spent a significant amount of time implementing the standards for Plan 9.
9:35:29
MichaelRaskin
Well, CLOSOS would need significant amount of work to implement the Common Lisp standard «Environment» part…
9:37:31
MichaelRaskin
As far as I understand, all implementations of SICL still assume a POSIX-similar OS that can provide FS and time tracking etc if asked, am I wrong?
9:39:05
beach
But in order to create CLOSOS from it, no files are needed, since everything is already resident.
9:47:51
MichaelRaskin
Maybe because I assumed that on HDDs this is a bit expensive time-wise, and on SSDs a bit expensive write-count-wise
9:48:03
beach
I think section 7.2 is the most promising, plus now that SSDs are cheaper, I think performance could be excellent.
9:49:11
beach
Well, there is new technology that doesn't seem to have the write limitation of the most common SSDs.
9:50:41
beach
Also, time is on my side. By the time I get around to actually implementing this stuff, it will be cheaper and faster.
9:51:27
MichaelRaskin
I guess you would need to get it to the state where it just obsoletes volatile RAM
9:52:49
beach
That a system like this could perform well, be more secure than traditional systems, that it will be much simpler than those systems, and therefore much more maintainable.
9:52:49
MichaelRaskin
Smalltalk «the universe is an image», OberonOS, FirefoxOS «Let's just run everything in a JavaScript VM» exist… and nobody seems to care
9:54:26
aeth
People could care about $OS if it's the OS of VR or AR or direct neural implants or whatever.
9:55:06
MichaelRaskin
If you look at the Linux kernel source — and I mean «count the lines», not «read the C code» — horrible maintainability problems seems to arise from hardware being a pile of garbage made out of lies
9:55:13
beach
Again, I have no illusions that CLOSOS could become widespread. I don't care much, and it is not my job anyway.
9:56:38
MichaelRaskin
In a sense, any widespread OS is more or less destined to have to be garbage (it has to be the OS that requires the least understanding from corporate purchase people and sinks resources into marketing not code).
9:57:09
MichaelRaskin
But I am not sure who of the minority of people caring about fine details is expected to be convinced of something by CLOSOS
9:57:49
aeth
You would have plenty of time, anyway. Standalone VR isn't going to happen anytime soon because VR generally requires very new/recent desktop PCs at the moment. A more exotic interface like a direct brain interface is even further away. AR might come sooner, but an existing mobile OS will probably pivot into that.
9:58:27
aeth
MichaelRaskin: I don't think quality has to do with it, it's just whatever happens to be around when the platform shift happens.
9:59:11
aeth
Lockin isn't really as big as it was in the past, though. You can do most things with a web browser.
10:00:39
aeth
MichaelRaskin: And on platform shifts, you can even see it with Linux, even though it didn't 'win' compared to Windows. It still beat workstation Unixes on non-x86 hardware when the world moved to x86 because Linux was there pretty early.
10:00:42
MichaelRaskin
aeth: getting a Web browser to run might is more work than emulating 16-bit Windows API, though
10:02:19
aeth
MichaelRaskin: Is it? Websites generally assume several entirely different browser platforms and test in them. A Windows app won't assume that it might be running under wine or a Lisp equivalent of wine.
10:03:46
MichaelRaskin
Windows applications assume that they are running under an unknown Windows release, which are still pretty different.
10:04:08
MichaelRaskin
(There are some applications, though, that run better under Wine than under newer Windows release)
10:04:52
MichaelRaskin
Web APIs are huge and horrible, and browser engines have a lot of platform-specific code…
10:06:02
aeth
The web is an awful platform for applications, but once you have a web browser, no one is going to call your OS incapable. And perfect emulation of Windows for a wide range of useful applications is much harder, considering that wine is incomplete and ReactOS still isn't complete, either, but dozens of OSes have functional web browsers.
10:07:12
MichaelRaskin
Dozens? Windows MacOS iOS GNU/Linux Android/Linux FreeBSD OpenBSD NetBSD — what have I missed? Well, DragonFlyBSD, I guess.
10:08:15
MichaelRaskin
And of course there is just 2.5 browsers, actually, across all of these platforms
10:08:57
aeth
Literally any OS made with a GUI since 1998 is going to have a web browser (and GUI is optional thanks to e.g. lynx). Start thinking about dead and near-dead ones (especially in mobile) like Symbian and WebOS and QNX.
10:09:37
aeth
In the old days, the third party browser the mobile OSes might have gotten was a version of Opera, but they had their own built in. Even Android used to, before they replaced it with Chrome.
10:10:03
aeth
I mean, yes, OSes that are dead or on life support aren't going to have modern web browsers because they stopped receiving updates.
10:12:21
aeth
90% of the difficulty of the web is compatability with legacy 90s crap that shouldn't have ever been done in the first place. If you had a 2007 web browser, you'd be in a much better place in terms of trying to get a modern browser engine than someone trying to write a CL one from scratch.
10:13:05
aeth
The web as a platform pretty much has to support everything forever except if it was a plugin (so Java applets and Flash are gone)
10:15:11
MichaelRaskin
Except if Google decides that they can get better performance numbers for Chrome by dropping something they started supporting three years ago
10:15:12
aeth
Most of the reason the modern web is bad is because every website wants to reinvent everything slowly and client-side from scratch with JavaScript. That's really just, write a JS engine in CL.
10:15:59
aeth
Stuff like video should be able to use a library, and basically just be a separate problem.
10:17:21
aeth
The thing is that the web is never fully valid, and even when it is, the versions aren't compatible with each other.
10:18:20
MichaelRaskin
And platform availability doesn't matter, both Symbian and Maemo were more mature than Android
10:18:24
aeth
If you wrote a CL web browser with its own engine, you'd have to pretend to be Chrome pretending to be Safari pretending to be Firefox pretending to be IE pretending to be Netscape.
10:19:23
MichaelRaskin
Actually, you are not likely to manage websites where claiming to be Firefox is not enough. Not anytime soon
10:19:48
MichaelRaskin
A lot of modern JS has actually seen the light of sane-ish feature-probing though. If only Common Lisp could have the same.
10:21:11
aeth
The problem is when e.g. one implementation wants to call it macos and another wants to call it osx and another wants to call it darwin. Also e.g. win32 vs. windows, or linux vs. idk gnu/linux (at least 'linux' tends to be a standard name in *FEATURES* afaik)
10:21:13
MichaelRaskin
That's nice, but there is no agreement on specific naming of any extensions, so people just probe for implementation signature in *FEATURES*
10:23:23
MichaelRaskin
But in total, it looks like implementing enough virtualisation to run a minimal Linux VM with Firefox has better feasibility than implementing an engine sufficient for the current garbage dump of Web
10:25:03
MichaelRaskin
Virtualisation is actually something feasible. How many hypercalls Xen has, a hundred?
10:25:42
MichaelRaskin
And it is a fantastically well-featured virtualisation system, you can implement less and still get by
10:26:45
MichaelRaskin
(And virtualisation probably will let you get away with reusing GPU drivers from another system)
10:31:57
MichaelRaskin
beach: Re: 7.2: if one wants to have both balanced writes (SSDs are horrible), and good performance, maybe it could be a good idea to split N sectors into √N groups, so that you check √N group headers to see where the circular head is, then read the group to pinpoint the exact location. If we have 10^6 of 10^3-byte sectors, we read just a few megabytes to find the starting point.