vacuity

Thank you for your comment. I will try to remember and apply it.

I have a similar concept, which is roughly described as "don't extend your own arm onto the chopping block, but make use of other people doing the same". Don't make presumptions, and you will never be wrong. Don't dig holes for yourself. Be kind, respectful, genuine. Don't throw the first punch, but don't let innocent people get hurt. Find common ground. When they extend out their arm, take their hand and guide them towards truth and goodness.

Perhaps I am wrong about Tit-for-Tat. It's been a while since I checked my source. In any case, my point (not to say that you deny it) is not to take any result in an idealized game too literally, and that consistent defection is bad.

I do not know your circumstances, but see what you think of this:

I have a nascent theory about human feelings, which goes that the basic feelings we experience are usually perceived through extensive filtering by our personal, social, cultural, etc., beliefs/experiences. The convincing conscious perception of a feeling may be misinterpreted to an extent. Anger is an emotion that can often become misdirected. Supposedly, sexual arousal can be interpreted in translation from fear[0].

Someone who is suicidal may consider suicide seriously, but feel an urge to live in the process of suicide. Circumstance may make certain feelings clear, but by examining removed from circumstance, the person had the capacity for both feelings. There is some "essence" to the person that those feelings, brought on by circumstance, only scratch the surface of. Observing a narrow range of circumstances and assuming it is the essence is a mistake.

I think that more or less every person, in their essence, understands human decency. It may be that some people truly don't have the capacity to appreciate it (thought: aliens?), but usually, I think the real culprit is learned behavior through various factors, and innate cognitive biases. I don't mean to say that it is easy to change people, because the opposite is generally true, but I think it is worth thinking about.

That said, if there was someone who truly needed to, say, murder the way we need to eat, I say that they would do no wrong by murdering, but that we would do no wrong by apprehending them. I wish to get to people at their essences, not their accidents.

[0] https://en.wikipedia.org/wiki/Misattribution_of_arousal

The optimal decision in the Prisoner's Dilemma is to defect, but in the iterated version, where multiple Dilemmas occur and people remember previous results, Tit-For-Tat is optimal. The real world is even less reminiscent of the Dilemma, so it's not at all clear that the Dilemma's conclusion applies.

(Tit-For-Tat: Prefer cooperating, but if the other person defected on the previous turn, defect on the current turn.)

As it turns out, maximizing profit for shareholders screws over everyone else...

Same. Somehow there tends to be some "pattern" that stands out, but I guess it's just a mix of the likelihood of "something interesting" and our minds being tuned to pick out "anything interesting". I've memorized a few SSNs and license plate numbers this way, and some digits of pi. I like it; it feels like normal memorization with a twist, without having to resort to "hardcore" techniques.

So the real test is waiting until the LLMs are inaccessible and then seeing what happens. Empirical testing!

I don't think it's so easy to get true information out of all the noise in the markets, and in any case, I don't see how this helps with the fact that corruption is bad. So what if I learn that a country will be wrongfully invaded? Can I have someone impeached for it?

But the market exactly provides a direct way to use power to make money. Why go for more cumbersome methods?

If a lot of people have that as their hobby, and some are careless or malicious, people will be harmed. Now suppose that it's not simple to stop the offenders directly. Instead, restricting the sale of nuclear isotopes or cholera samples would probably be highly effective.

I agree that I should understand the other person and take them seriously, and to convey this to the other person. However, sometimes verbal reflection serves the purpose of blind affirmation. I don't think the verbal component, construed this way, is so productive for empathy.

Military action would be brutal, but you can only say that it's unnecessary if the alternatives are better. If not now, then how many years down the line? The claims Carney are making are not light in their own right.

while pushing aggressively progressive ideas

The establishment Democrats are not exactly "aggressively progressive" by any reasonable standard. They shunned Bernie Sanders, who still isn't highly radical.

Rather, Russia attacked Ukraine as a great power oppressing a smaller power, and had every opportunity to cease, with or without international intervention. No one attacked Russia first.

Someone had to take the plunge. Regardless of the other political considerations at present and whatever future events will happen, I respect Carney's initiative. I also appreciate the reference to Havel's essay; to me, its insight always felt obvious but also difficult to apply. But framed in this way, I understand. For some time, I've felt that the United States has been the leading example of a country that is powerful through narrative. Narratives are naturally idealized, but at some point the gap becomes too large to tolerate.

I'm not qualified to give a complete answer, but I think two main issues are the proliferation of flags in standard tools (e.g. ls has a lot of flags for sorting behavior) and the extreme preference for plain text. Text is very useful, but a lot of semantic information gets discarded. Representing structured data is painful, stdin/stdout/stderr are all in one place, window resizing makes a mess sometimes (even "write at end of line" isn't given), and so on. I'm definitely not qualified to describe just how to fix these issues, though.

I think this is an after-the-fact connection, rather than an intuitive discovery. I wouldn't explain memoization this way. Memoization doesn't need to specifically use an array, and depending on the argument types, indexing into the array could be very unusual.

I'd like to add that, while anything will have some learning friction, learning the Unix CLI is rather unnecessarily painful.

For the time being, I consider alloc and std to be part of the language, and the compiler also has provisions for them if they are used. If the alternative is supposed to be only using core, then the language does not provide for control over allocations the way Zig does. Imposing allocations with no control and not providing allocations at all are both failure modes. With enough effort, anyone could do anything, but programming languages exist to control and enhance certain things under their purview. Rust does not have a comparable facility to control allocations like it controls ownership and borrowing. Just as C-with-tooling being safe isn't the same as C being safe, Rust-with-libraries providing control over allocations isn't the same as Rust providing control over allocations.

Other people have given good insights, so I'll instead describe one of my pet theories.

Given by how we talk about emotions, I think they are "rational", but operate under a different set of rules than we normally apply to "rational" thinking. In fact, feelings are deeply intertwined with our supposedly "rational" thinking, to the point where I don't think there is a significant boundary. The lack of information is prevalent when feelings are in play, and I believe the same is true in general. Even physics feels far different than pure mathematics, after all. Instead of deferring to conventions in how to act when feelings are involved, as if they belong to a wholly different and mysterious world, we can make sense of the entire world. But of course, empathy, kindness, and good judgement are not exempt. None of this conflicts with what you're saying, but I think a subtle shift in mindset will be fruitful in applying it.

You described one of my misgivings better than I could (I made a sibling reply to parent), but I don't agree with this in all cases. Anger is easy to perpetuate blindly, but I think introspective feelings sometimes can die out if they aren't affirmed. Someone struggling with an internal conflict may reject a feeling that seems to resolve the conflict, and not take time to properly deal with the feeling. Affirming the feeling should affirm that the person may have felt and be justified in the feeling, without assuring that the feeling is definitely justified. Maybe taking that road is indeed foolish, but it would be too hasty to dismiss doing so just because it feels foolish.

I agree with your descriptions of the terms, but I think there's often a divergence between empathy (which I find great) and reflecting people's feelings (which I find good with caution). I want people to understand and help each other. But in some situations, reflecting people's feelings encourages them to make poor decisions. I should always provide a space for people to speak without scorn and with understanding, but I don't want to give a false impression of my concerns. Acknowledging that someone's life sucks is subtly different from acknowledging it aloud, and sometimes the subtlety is crucial.

I don't think the "complex web of objects to be deallocated" scenario is usually a problem, but I generally agree with your points. As always, careful design and control of the software is important. Abstractions are limited; spend them carefully.

It is perfectly possible to deal with hardware in managed languages.

Perhaps we're using the words in different ways. What I mean is: in order to interact with something, it must either be done directly or through abstraction. If abstraction is used, it must be realized without itself. A language such as Java or C#, at least for performance, must expose some things on a lower level that the runtime normally abstracts away. (Or, say, the OS memory manager can't use virtual memory before it enables virtual memory.) Technically, the lower level could be programmed with a dialect of Java/C# or something like that, or there may be another level of abstraction that hides the details (a compiler generating code in the background, for example). But something has to be the first step at the bottom.

Yes, IPC is context switching.

(Considering the diversity of how OSes approach context switches/IPC, I use "context switch" to mean "CPU mode/address space switch", more or less.)

Usually, IPC is context switching and overhead. seL4's IPC has overhead involved with scheduling, threads, and message buffering. My design isolates the context switching, which is common to all IPC designs.

Timer interrupts can cause extra context switches.

I don't see what your point is. I assure you that my system is not uniquely fragile to timer interrupts.

It's trivial, except for the little problem that your userspace program can be killed and then you have no scheduler.

Then don't let the scheduler be killed. What is the difference between a privileged userspace program and a kernelspace program? Isn't that what microkernels demonstrate? Again, this has been done before.

Ok. If you want to use a different description of the term syscall than is common then that's fine but you should define that up front. Your definition of a syscall simply does not match mine.

It wasn't quite a definition, though I did write poorly. In the abstract, a syscall can be seen as a message. If IPC ("to a process") is done by putting some data somewhere, setting a few registers to special values, and executing a magic syscall instruction, then a normal syscall can be considered IPC "to the kernel".

https://old.reddit.com/r/rust/comments/1op6g64/whats_the_sta...

This Github thread is also interesting (transitively reached from the above Reddit thread):

https://github.com/rust-lang/rust/issues/32838#issuecomment-...

https://news.ycombinator.com/item?id=46684673 (reply to sibling)

I think it's fair to expect that it will stabilize in time.

The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though.

Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required.

This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.

So, that is not done at the language level but the library level. Unless the compiler is modified for Linux, but even if it is, that's entirely bespoke and unstable. This is not comparable to Zig's design. I'm aware that anything can be done if the right things are implemented; I'm talking about what Rust-the-language currently does for control over allocation. If the answer comes down to "we're doing something custom", then the language is soewhat or largely sidestepped. C-the-language certainly doesn't have panics or exceptions, even though longjmp or a custom runtime could be used.

The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.

The parts that touch hardware (or similarly bare kernel interfaces) must be so. Sure, you could split device driver implementations and so on, but somewhere there's a meaningful lower level of software within the system.

Because any other solution will quickly run into chicken-and-the-egg style problems.

No. The kernel must provide for context switching. It would be like migrating threads IPC, but one-way. No threads, no scheduler, no dedicated data transfer. In other words, the bare minimum necessary to make a sensible abstraction around switching processes.

seL4, according to its developers, is not absolutely a microkernel. I believe the rationale mainly points to the in-kernel scheduler, but seL4's IPC interacts with the scheduler and is noticeably more elaborate than a mere context switch. Even if seL4's IPC is, by most standards, minimal, I do not consider it to be so objectively. I described a meaningfully more minimal alternative.

Delegating scheduling to userspace is trivial. If necessary, designate a scheduler to run if no scheduling decision is available. It has been done before, and the only usual objection is performance.

No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.

Just as hardware interrupts can be abstracted into messages, syscalls can be abstracted into messages. I'm not saying that the hardware implementation directly conforms to the abstraction.

That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.

The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages? Essential complexity can only be rearranged, not removed. Nothing changes the fact that every interface between hardware and software needs to be bridged.

On a different note: why should the kernel even handle IPC or scheduling? Those take the basic capabilities of context switching, timer management, and memory management. Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server? Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction. Everything else either follows from the hardware or is left to the whims of software.