freenode/#sicl - IRC Chatlog
Search
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.
13:12:38
MichaelRaskin
Well, it also reduces the maximum overwrite rate of any specific sector, as the separate-header-space risks getting a lot of writes
13:13:16
MichaelRaskin
So it's an optimisation to have boot speed bearable and not pay too much in terms of storage wear
13:47:37
MichaelRaskin
Hm. How CLOSOS should deal with a user's wish to make-array something of size 4GiB?
13:57:37
MichaelRaskin
In the address space section you refer to a compacting GC paper, in the GC section you say that the object addresses do not change during GC
13:59:15
beach
Ah, that may be some oversight. The SICL specification has the current best version of GC that I can imagine.
14:03:38
MichaelRaskin
Do you still plan that the global heap space maps directly to secondary storage?
14:09:25
MichaelRaskin
Is there any allocator strategy involved re: address space (I guess you need some kind of per-size pools for small objects, but everything large thinks in terms of pages anyway)?
14:11:28
beach
Yes, most small-ish objects are allocated on the thread-local heap, and migrated to the global heap only when they become old.
14:12:07
beach
Large objects, and some types objects like code objects are always allocated on the global heap.
14:13:27
beach
The write barrier checks whether an attempt is made to put a pointer to a thread-local object in a shared object, and then first migrates the thread-local object to the global heap.
14:18:33
beach
By the place of the space allocated in the address space. It is basically a malloc/free collector.
14:20:06
MichaelRaskin
I guess I have failed to ask clearly, as the answer seems tautological to me; what policy for address space allocation should the corresponding malloc use?
14:23:17
beach
The answer is the name of a person, but I temporarily forget his name. The appendix in the SICL specification has a detailed description.
14:24:01
beach
It is a slight modification of the allocator that seems to be standard on Linux systems if I understand things right.
14:29:09
MichaelRaskin
I think you have a typo where |c|≥n but then you compare |c| with n-4 instead of n+4
14:30:43
MichaelRaskin
Well, that's exactly a kind of typo that is easy to miss when rereading if you remember the idea well enough
14:32:00
MichaelRaskin
I think it looks like you have not fully committed to chunks either divisible or not always divisible by 4
14:33:04
beach
Since my memory is so bad, I can't tell one way or the other at this point. I'll keep that aspect in mind as well when I re-read it.
14:34:35
MichaelRaskin
Oh right, you sometimes talk in terms of words and sometimes in terms of bytes
14:36:02
beach
I don't pay attention to what individual vendors define as "word". DEC/VAX had 16 bits to a word. Intel, I don't know.
14:36:44
MichaelRaskin
Well, the current text seems to imply 4-byte words, and also that addresses fit into a single word
17:13:15
Bike
i'm implementing the sequence extension and looking for examples of libraries that define their own types of sequence. the paper mentions flexichain as an example.
17:13:44
Bike
but it looks like flexichains aren't used with any of the derived sequence operators like map or find.
17:16:26
beach
Yes, this thing was written before the sequence extensions existed, and before I had improved my programming style. :)
17:36:24
Bike
but if you're not using the CL sequence functions, the etexnsion isn't that interesting. it just lets you name your accessors length and elt, which isn't nothing, but it's not as useful
18:48:21
shka_
https://github.com/sirherrbatka/cl-data-structures/blob/01e78b634bef95816ddda6a388c0ce3c036c9372/src/sequences/rrb/tests.lisp#L74
19:11:35
shka_
because i have flexichain dependency (used as double ended queue, even though i have my own double ended queue already)
19:22:18
Bike
beach: i don't know what you use a gap buffer thing for, i guess. other than text editing, and i don't know hwat kind of operations you need for that
19:24:45
shka_
Bike: across and traverse, they are the same for the purpose of the containers, but there are also ranges, traverse will mutate range, across will not
19:29:44
shka_
anyway, gist of this is that there are containers, cl-ds:sequences are containers, there is protocol constructed around inheritance order traversable->fundamental-container->fundamental-sequence->mutable|functional|traversable
19:31:45
shka_
then mutable|functional|transactional variants provide means to modify the content of the container
19:32:05
Bike
if you had a set object, would that be a traversable but not a container? since at doesn't make sense
19:36:57
shka_
Bike: don't have high expectations regarding docs, It was written by me and I didn't an help with it