| 1 Nov 2023 |
|  @zardo3z:laborde.live changed their display name from zardoz to Mick O'Carbomb. | 13:19:30 |
| 11 Nov 2023 |
| @zardo3z:laborde.live changed their display name from Mick O'Carbomb to zardoz. | 12:38:29 |
| 16 Nov 2023 |
|  Gnuxie 💜🐝 changed their profile picture. | 14:05:07 |
| 20 Nov 2023 |
| @zardo3z:laborde.live changed their profile picture. | 10:48:45 |
| 30 Nov 2023 |
| @zardo3z:laborde.live | silly question but is netfarm similar to utena but with different goals/intentions | 15:50:48 |
| @zardo3z:laborde.live | since i think netfarms is also message passing for the replicating objects across networks but i dont think it intends to be ocaps unless i am wrong | 15:52:32 |
| Gnuxie 💜🐝 | Netfarm came before and sort of during Utena. Originally even Utena wasn't conceived with Ocaps in mind, it just became a kind of natural progression when later on it became clear we would have to throw out prototypes. The global environment (or lobby object) from Self was never really considered until a lot later on so there was 0 (and no emphasis at all, there was nothing needed to change) to just say "there will be no global environment". | 16:47:01 |
| Gnuxie 💜🐝 | (I'm not Hayley, who designed Netfarm but) Netfarm is designed around computed values and presentation scripts with user extension of basically anything built with Netfarm in mind. Neither of us had really come across ocaps and stuff when it came about though I think later on Hayley did revise some stuff. Utena is more of a fundamental step for "how the hell should we do computing in the first place" and Netfarm is a platform for any kind of distributed application you would want to make. | 16:51:46 |
| Gnuxie 💜🐝 | But implementing something like Netfarm on Utena would be easier than on CL or something | 16:52:29 |
| @zardo3z:laborde.live | seems definitely easier since iirc u wrote in one of the utena intro docs its meant to be more async than CL can provide, since iirc you said signals have to be reworked (and possibly standards breaking) if they were to be async in CL | 16:53:54 |
| Gnuxie 💜🐝 | promises and futures are fundamentally incompatible with CL's dynamic environment in general. So the argument is that you would have to get green threads on the implementation level if you wanted to comfortably do async stuff in CL without sacrificing the dynamic environment which is an essential feature, and for me it's also probably the reason why i would even use CL to begin with (in regards to how it allows conditions with restarts). The problem is that there is no specified concurrency model in CL so any program you write that does rely on implementation detail of green threads will not be portable (and on top of that there's no appetite for implementations to really make light weight threads or otherwise since there is a big scientific computing community using CL, who need native threads). | 17:03:12 |
| Gnuxie 💜🐝 | but in general any code with IO is easier with green threads | 17:04:00 |
| Gnuxie 💜🐝 | since they can be written in direct style | 17:04:11 |
| Gnuxie 💜🐝 | but that's not the biggest reason why Netfarm would be easier. Utena is designed so that in future programs (whether alive, or within class definition mixins) can be shared trustlessly | 17:08:06 |
| @zardo3z:laborde.live | i think also it would be good for say nyxt to be in utena rather than say CL | 17:09:27 |
| @zardo3z:laborde.live | as i understand it correctly they have read-time-eval bugs | 17:09:41 |
| Gnuxie 💜🐝 | I really don't like the developer of Nyxt | 17:09:50 |
| @zardo3z:laborde.live | * as i understand it correctly they have read-time-eval exploits | 17:10:21 |
| Gnuxie 💜🐝 | He has been an arrogant snob towards people in the community and was (no idea if he still is) reliant on the help of community basically daily to do pretty simple things and he refused to join #clschool | 17:11:14 |
| Gnuxie 💜🐝 | so i wouldn't really trust them to be able to program a web browser | 17:11:35 |
| @zardo3z:laborde.live | i was not aware of this and it makes a lot of sense | 17:11:45 |
| @zardo3z:laborde.live | since i remember seeing a blogpost shared with whatever developer saying that you can basically do (defun safe-read (s) (let (*read-time-eval*) (read s))) but having that exact vuln in 3 places | 17:12:47 |
| @zardo3z:laborde.live | * since i remember seeing a blogpost shared with whatever developer saying that you can basically do (defun safe-read (s) (let (*read-eval*) (read s))) but having that exact vuln in 3 places | 17:13:54 |
| @zardo3z:laborde.live | because a web browser has to be trusted and that does not mean evaluating things with trust they don't do #.(uiop:run-program ...) | 17:16:55 |
| @zardo3z:laborde.live | it means that it has to run shit trustlessly | 17:17:07 |
| Gnuxie 💜🐝 | i mean, there'd have to be a system in Nyxt where you can run random people's CL or cl:read is used to do something like read a list from untrusted input (this is more common) | 17:23:20 |
| Gnuxie 💜🐝 | i mean, if extensions in Nyxt are just like running a dependency from quicklisp, then the risk level is already about the same as using CL to begin with | 17:24:55 |
| @zardo3z:laborde.live | the main difference is that if its for non-networked software the risk is minimaller given read-eval problems are not going to be as glaringly bad | 17:26:24 |
| @zardo3z:laborde.live | * the main difference is that if its for non-networked software the risk is minimaller given *read-eval* problems are not going to be as glaringly bad | 17:26:35 |
| @zardo3z:laborde.live | * the main difference IMO is that if its for non-networked software the risk is minimaller given *read-eval* problems are not going to be as glaringly bad | 17:26:43 |
