Notices by LisPi (lispi314@udongein.xyz)
-
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 20:03:19 JST 
LisPi
@p @scathach @jeffcliff @sicp @Suiseiseki It's not even the rights assignment all that much (though it is distasteful at best), it sucks in that aspect, but the hard no-deal is the mandatory doxing (which they incidentally require for the corposcum behavior). -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 15:39:37 JST
LisPi
@sicp @scathach @jeffcliff @p @Suiseiseki I have been keeping an eye on Genode, though I am disappointed by the contribution agreement.
Working on it (rather than with it) would consequently require forking it.
> Unless you're doing pure message passing it sounds like you'd need either a runtime or some hairy control scheme in order to get this to work.
If the system is a Lisp runtime with support for first-class global environments, that one runtime is enough.
Otherwise one gets back to process-based separation using the kernel and messaging overhead goes back up. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 15:28:15 JST
LisPi
@sicp @scathach @jeffcliff @p @Suiseiseki > Sounds proprietary. :absolutely_proprietary:
It's comparable to a lambda in Emacs Lisp (to a more limited extent, Elisp gets weird about the lexical vs dynamic situation and there are a bunch of caveats) or Common Lisp.
One can put access to some resources inside of one, and from within the language there is simply no way for anything receiving that lambda to crack it open and retrieve that resource (at least without messing with FFI and starting to parse the runtime's memory).
> A process shouldn't have to give away the resources you don't need, but whatever you get your hands on you should be able to do with what you please. If you're just sending blunt data it's not even a problem.
Consider C as the host language. It permits any function to dig into any memory it feels like. There is no simple way to have separate programs share memory without also enabling ambient authority of that sort.
And so an additional runtime capable of enforcing sane isolation properties becomes necessary.
That said, Common Lisp as standardized isn't sufficient for a single runtime with arbitrary program threads. Nesting environments without arbitrary access to others (via various dynamic/special elements) would be necessary (concepts written about in SICL, first-class global environments). -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 15:17:22 JST
LisPi
@p @scathach @jeffcliff @sicp @Suiseiseki > I have not ever seen a case where serialization was slower than the disk or the network.
Any slowdown including that initial delay is undesirable, but that initial one can't really be eliminated. That's no reason to keep the others.
> I shove a 20GB log file through awk and don't have this problem. Fancy NVMe storage, ARM CPUs (and gcc still sucks for optimizing ARM), and *still* everything is I/O-bound.
You're using a single awk program instead of a bunch of programs with pipes & buffers between each (and no real need for serialization either).
Obviously it'll work fine. Epsecially since awk was designed for the specific kind of text processing you're doing.
Split out every one of the tasks into a different program and pipe them, you'll get the kind of result I'm talking about.
> The perpetual lament: "this machine was written to run C and Unix, Lisp would be faster if the CPU and the OS and the compiler were designed from the ground up to be faster for Lisp". It's always asserted and never backed up with a working CPU design. We've got FPGAs all over now, you can do this at home, implement type-tagging in the MMU, go nuts. Build it and get back to me.
There's no need for that.
>> We've got half of those. I think you could assemble a plausible Lisp workstation if you build out the Lisp environment on top of the rest. That is, you do it like OpenStep/GNUStep, or like Arcan.
That provides the same kind of environment I'm suggesting.
Medley Interlisp would be another historical example of that overlay environment concept. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 12:47:00 JST
LisPi
@sicp @scathach @jeffcliff @p @Suiseiseki With a language providing no direct memory access semantics, it is impossible to wrongly access resources without either a broken implementation (for which formal verification methodology is available) or broken hardware (this is a more complicated issue).
This means the implementation can encapsulate resources in opaque structures which cannot be interfered with.
Implementations/compilers can provide APIs for handling cases where such memory access is required, namely hardware support.
> And I don't get how that answers network-transparent storage and IPC; those bits don't just emerge out of thin air.
Neither Erlang nor Goblins have that as zero-cost, they have considerable overhead even if one were to run the messaging for them over RDMA (which requires considerable node trust).
It may be impossible (with near-zero cost) without complete node & network handler program trust. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 06:53:44 JST
LisPi
@p @scathach @jeffcliff @sicp @Suiseiseki > but you suggest it and it's even odds you hear "We already have emacs, which is already perfect, please let us stagnate in peace."
I think everyone acknowledges that Emacs sucks for the overwhelming majority of graphics-related tasks.
It does considerably worse than Interlisp does at it. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 06:41:00 JST
LisPi
@p @scathach @jeffcliff @sicp @Suiseiseki > HTTP is about as inefficient as a protocol gets: how many webservers' big bottleneck is dealing with the serialization of the requests and responses? That part's negligible: the performance focus is on the easiest way to poll a large number file descriptors.
Think tools on one's own system instead. It is a *lot* more common for serialization pipelines to become a bottleneck in local data processing, particularly when the storage backing is sufficiently fast to not be the bottleneck.
The point where using a program instead of a pipeline to have something barely complex complete within a reasonable amount of time comes pretty quickly.
Communication efficiency matters and serialized text pipes are not particularly efficient (both from serialization and various Linux-related slowdowns). There is a reason many messaging libraries use shared memory as a transport when possible instead of local sockets.
> You absolutely do have serialization overhead even if you are using Common Lisp to talk to Common Lisp.
Only if you have not designed the compiler and library to provide an interoperable type usable from both Common Lisp and the hosted language natively without needing further transformations.
There is some impedance mismatch that may be unavoidable when the languages differ sufficiently, yes.
Observe how protobuf has high impedance mismatch with *everything* instead (it all needs binary serialization). That's not fixing the problem, because that isn't the problem it is intended to fix in the first place.
> (the ethernet chipset will hand it to the kernel, the kernel will place it into the buffer, and the next syscall will get that buffer either copied or remapped into the address space of the calling process)
Most affordable ethernet chipsets are not capable of RDMA. So yes, that is how it goes and that's what one is limited to as a result.
> Plain text is pretty easy to convert to a bytestream, because the overhead is zero: plain text is a bytestream.
Unless you're using stringly-typed languages on both ends, there's overhead converting it back & forth its computation-usable form. Or are you exclusively processing strings?
Even so, with enough fields there is some overhead in needing to traverse the string for separators instead of having an indexed structure.
> using less CPU
You ackowledged that this can just as well be indicative of IO or syscall bottlenecking. And yes, the latter is a thing I've observed.
> they spend more time waiting for read() or write() than they do calculating a rolling average and stddev and then deciding if the current event they are observing is aberrant, and they spend more time doing that than parsing the input.
And if one is unsatisfied with the runtime, the optimization/refactoring targets first considered would be the IO, decision computation and parsing (in this order). The easiest with money would most likely be the IO, and then the parsing, unless one did something wrong and trivially fixable with the decision-making. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 09-Apr-2025 04:08:39 JST
LisPi
@sicp @scathach @jeffcliff @p @Suiseiseki > to parse lines of text or TSV or something. I'm all for S-expressions but it's not like you need a hard format to have structured data.
And promptly performance has just dropped by a magnitude or more.
Compiling various languages to Common Lisp (or some other host language) and running programs in its environment allows for safe near zero-cost IPC (through the use of object capabilities for maintaining isolation in memory) with no serialization overhead.
9p has a lot of such overhead. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 08-Apr-2025 15:27:34 JST
LisPi
@Suiseiseki @scathach @jeffcliff @p That (no ABI) requires a hosted language-based system in order to have adequate structured messaging capacity.
It also requires the language to have a fairly rich type-system, otherwise that will be a wasted effort and guest languages will yet again have to formulate supplementary interchange formats will all sorts of unwanted slowdowns as a result.
That being said, source availability is irrelevant to a program's nature as proprietary malware. Source-available proprietary malware is readily available. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 08-Apr-2025 15:08:28 JST
LisPi
@p @scathach @jeffcliff @Suiseiseki There's no reason not to have a standard system ABI and/or an environment for hosting programs atop of that permits for abstracting those concerns.
This doesn't require strongly coupling programs. They can remain separate, and written in separate languages. All that is required is a compiler adequate for the target environment and/or some abstraction interface library to interface with said ABI or environment properly & transparently.
Whether structured messages can be passed directly or require ABI interpretation shouldn't be the programs' concern beyond that. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Sunday, 06-Apr-2025 22:05:25 JST
LisPi
@coppertiel @dalias Spelling out the constant is more confusing tbh, makes it look like a variable. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 01-Apr-2025 11:59:18 JST
LisPi
@linux_mclinuxface @3dprinting @koz Aren't those synonymous?
Using cheap parts /is/ bad engineering. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Saturday, 29-Mar-2025 11:54:47 JST
LisPi
@prettygood @aliss She sounds like great company.
Don't think I can do dating (in general), but friends is fine. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Friday, 28-Mar-2025 14:32:20 JST
LisPi
@sendpaws @navi @Suiseiseki @KaiserKitty GNU Hurd could potentially be used to make something reasonable, though it'd need a lot of work and some of its design (which is noted by the project members themselves) is non-ideal. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Friday, 28-Mar-2025 13:27:22 JST
LisPi
@navi @sendpaws @Suiseiseki @KaiserKitty GNU is not UNIX (nor POSIX), but it is problematically UNIX-influenced.
Fuchsia meanwhile is a corposcum user-abusing project that not only spoils its own potential but inexplicably sabotages its own foundations with incomprehensible technical choices. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Friday, 28-Mar-2025 13:19:32 JST
LisPi
@Suiseiseki @navi @sendpaws @KaiserKitty There's no need for POSIX obsession to make a system interesting or useful.
Fuchsia has a lot of problems, but they're entirely orthogonal to UNIX & POSIX.
Or do you mean that GNU should make a new set of tools for Fuchsia, hopefully with no POSIX/UNIX mental pollution? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Thursday, 27-Mar-2025 17:21:25 JST
LisPi
@kakafarm @anemone > Extreme Leftists promoting bigotry
I think Lunduke might not understand what leftism is supposed to be about.
Someone attempting a false flag doesn't make that someone a leftist. Just a liar. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Thursday, 27-Mar-2025 13:12:34 JST
LisPi
@Suiseiseki @gentoobro @famfo Domains introduce an authority problem in their most common form.
They also introduce authentication problems as it is mostly not used in conjunction with key-addressing.
Effectively, user-configured petnames (ref: Zooko's Triangle) and key addressing as Yggdrassil does is the only sane way to communicate at the application level (yes the implication is that there's no sane way to use IPv4 as it cannot encode a sufficient key).
The keys need not be encoded in IPv6, the underlying transport layer may be abstracted. But applications should not concern themselves with routing details (unless they are specifically overlay network programs, of course). -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 25-Mar-2025 14:34:04 JST
LisPi
@Suiseiseki @nimrod @KometFox It is however still wasteful to bury it when it could just be reprocessed and reused in different reactors. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 25-Mar-2025 09:17:55 JST
LisPi
@mcc @mattblaze @ai6yr It helps when one would get a lot more than just jail if one doesn't comply.
A subpoena would also only apply in cases where one doesn't have a Right to Silence. (The UK is one such nightmare state.)
All GNU social JP content and data are available under the