Notices by LisPi (lispi314@udongein.xyz)
-
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 13-May-2025 06:54:34 JST 
LisPi
@lanodan @a1ba They sell stickers for that too.
Manhua presence is unexpected though. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Friday, 09-May-2025 11:57:21 JST
LisPi
@gentoobro @skylar @davidaugust @pluralistic Uh-huh, right... how much do you want to bet they very much invent their own culprits on a frequent basis? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Friday, 09-May-2025 11:57:12 JST
LisPi
@davidaugust @pluralistic Makes El Salvador sounds like a totalitarian shithole.
How far off the mark is that impression? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 29-Apr-2025 20:49:23 JST
LisPi
@lain Which one? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 29-Apr-2025 20:12:08 JST
LisPi
@angelastella @wakame Well, that is one way yes, I was mostly wondering how this specific instance by @markarayner does.
I would be inclined to have a dedicated autorepeat on/off switch and leaving it off entirely most of the time. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Tuesday, 29-Apr-2025 12:19:24 JST
LisPi
@koakuma I cannot -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Monday, 28-Apr-2025 07:00:55 JST
LisPi
@georgia You didn't dox yourself sufficiently for their desires? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Thursday, 24-Apr-2025 14:33:53 JST
LisPi
@Natanox @CiaraNi @jalict > It should just work, tinkering with it doesn't have to be exciting.
Here bidets are aftermarket add-ons (built-in is far too overpriced). Not anything exciting or complicated, but something that needs doing anyway.
I don't use a car, but apparently with newer DRM-locked cars it can be necessary to modify the seats to enable heating feature & so on.
> To share a buyer's guide for ready-to-use Linux devices would be more useful in most cases.
I would recommend against using pre-installed OSes in /general/, whether Linux, Windows or something else.
They usually come with pre-installed bloatware and potentially malware.
Linux distros tend to come with weird nonstandard package repositories that aren't properly maintained. -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 16-Apr-2025 19:34:39 JST
LisPi
@Suiseiseki > There is the option of putting a power conditioner in between, but those are is expensive.
Yeah, in theory and practice that should work, but I'm weirded out by the manuals for conditioners warning against that use. Whatever else do they expect them to be used for? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Wednesday, 16-Apr-2025 19:18:16 JST
LisPi
Utterly befuddling.
Double-conversion UPS manuals that warn not to use with an alternator generator. Other equipment for power correction by the same company carrying the same warnings.
wtf is one supposed to use then? Are they just expecting one to melt the generator for scrap and buy an inverter one instead? -
Embed this notice
LisPi (lispi314@udongein.xyz)'s status on Sunday, 13-Apr-2025 17:20:37 JST
LisPi
Even if the clipper chip had been made widely present/available, would it even have seen any use?
The OpenBSD-like approach of just refusing to use hardware accelerators would have defeated its point.
Proper (software-based) encryption could have been used atop it.
Was anyone pushing it even thinking about it for a few minutes? -
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.
All GNU social JP content and data are available under the