I still prefer Go over the alternatives because I'm reviewing the code carefully and trying to make it all look as good as if I'd written it very carefully by hand.

The few times I've needed a language without a GC and used Rust and C as target languages, I've reviewed the code less and enjoyed it less.

Whether they can compete on decision models or not, TypeSafe showed that a lot of the market had missed something important. With this much money, they have a lot more chances to discover other important things that are missing.

Cross posting to Bluesky too would be cool, and reach even more people. There are many ways to post, but lots of people use https://typefully.com

Maybe use Bridgy on a Mastodon feed?

"It hurts when I do this"

"Stop doing that"

If you care about latency, disable swap. System wide or for the specific the cgroup.

This is not entirely correct. If you care about latency, then it doesn't matter on which major fault your application gets paused. Disabling swap protects you from data pages being evicted, but code pages can still be paged out.

If you care about latency, mlock() your memory, do not disable swap. Swap is good and gives the kernel an equal opportunity to evict data and code pages.

For GC enabled languages swap is universally bad. Some gc-pauses are indistinguishable from a system crash. It's a side effect on not having tightly specified memory limits.

I'd rather have applications be oom_killed than having them swap out, the former is rather obvious and demands action.

If you want you application to stay in memory, then make it explicitly with mlock()/mlockall().

Disabling swap will just moves pressere elsewhere: to code pages. And evicted code page is no better: full stall while kernel loads that page from disk.

FYI: This `delamon` account seems to be meat proxying us. Just relaying garbage AI answers without understanding his own words. Doubt he's ever used mlock himself for anything.

His reply below was presumably killed by mods for doing this: https://news.ycombinator.com/item?id=49970841

I'm not. If you think that I said something not correct, do correct me. We're all learning.

I see that you've rewritten your AI generated reply there. So when have you used mlock in production for Go services, the way you're advising others to do? What were the circumstances?

I did not rewrite anything.

Yes, I was and still running go and zig binaries with mlockall. Apps have large in-application caches and also perform large streaming reads of datasets bigger than available RAM. If it happens that several streaming reads running at same time, they push memory pressure hard enough, so kernel swaps out cold parts of in-app caches. That later leads to elevated latencies => mlockall to avoid that.

While I've seen systems grinding to a halt due to evicting code pages, the idea that disabling swap distributes load between code pages and data pages makes no sense to me. Data pages are also disk backed, so they could also be evicted at any time. Why would data pages be written to swap if they came fron the disk in the first place?

So that only leaves anonymous data pages, i.e., regular data in memory, that could be swapped. Ok but you're not easing the load on code pages, those still get evicted during memory pressure whether you have swap or not.

The assumption that data pages can always be easily discarded is incorrect. Dirty data pages can't be discarded until they are written back. Recently accessed data pages are also not discarded until all inactive data and code pages are discarded.

I think discussing it in a vacuum is pointless, it should depend on how much memory you have. You can have a swap on, but with a low `vm.swappiness` number.

The point is that disabling swap does not prevent page eviction. Instead of swap, this discussion should be about the page cache.

Surely as long as it is all in memory these pauses are not going to be that significant, details like that should be left for the language devs to optimize.

You can tell an average Golang user to use mutexes, you shouldn't be telling them to lock memory manually.

vm.swappiness doesn’t work the way most people assume it does. and it is ignored under heavy memory pressure.

Maybe, but it still there and probably has a different value between distros as well. Default value is 60, what is that good for exactly?

If you're in a position where you still want swap to be there, but only used in extreme situations, then you should set it yourself. Otherwise disable swap or switch a language.

What do you think this value of 60 means? Also, as I said, in extreme situations, when the system is right before invoking the OOM killer, swap is used regardless of `vm.swappiness` setting.

> What do you think this value of 60 means?

Some arbitrary number.

https://docs.kernel.org/admin-guide/sysctl/vm.html#swappines...

> At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.

I don't see a reason why the default shouldn't be 0 then on modern systems.

Value 60 is not an arbitrary number. It makes the kernel reclaim 140 file pages for each 60 swapped-out anon pages. This proportion is supposed to reflect the relative performance cost between sequential file access and random swap I/O on HDD. For SSDs, the value 100 is more appropriate.

> I don't see a reason why the default shouldn't be 0 then on modern systems.

The zero value makes reclaim very unbalanced and is not appropriate for generic systems. This will cause the kernel to discard all the page cache, slowing down the system with uncached I/O, while keeping all unused anonymous pages in memory.

I don't get the point that you're even arguing. Are you saying that 60 is fine as a default? Or are you saying that people should even think about vm.swappiness because it doesn't matter? The alternative here is to disable swap completely, that's what started this whole thread.

> If you care about latency, disable swap.

There are two types of pages: anonymous and mapped from files. The code pages are mapped from a binary; they are not very special.

Under memory pressure, the kernel evicts less popular pages from memory. If a page has been mapped from a file, it is dropped (if dirty, then it is written out first). If it is needed later, the kernel can read it back from the file. If a page is anonymous (read: heap page), then there is no backing file and the kernel copies it to swap before dropping it. This is swapping.

So, what happens if you disable swap and the kernel is low on memory? What can it evict? Anonymous pages cannot be evicted: there is no swap to put a copy in. The only choice the kernel has is to evict pages that are mapped from files. Those include pages mapped from the executable. You don't eliminate stalls by disabling swap, you just move them elsewhere: the kernel will page out code and your app gets paused whenever the execution flow hits such a page.

Thanks for the clarification, learning everyday.

I haven't had to analyze the performance of no-swap processes before. My assumption is that code is hot enough to avoid eviction and that evicted code pages are rather the exception. To strong-man the argument, I can imagine long running complex (bloated) services could have parts that are not touched unless a specific request comes in.

>So, what happens if you disable swap and the kernel is low on memory? What can it evict?

Your userspace early OOM killer triggers and lets you know you're trying to run more than will fit in memory so you don't do it again. (In my experience, the kernel OOM killer can't be trusted to kill processes soon enough.)

You are missing that the file LRU is not only the code pages or memory mapped files but all file data. The active code pages are specifically excluded from being discarded during the reclaim process.

I wish this is true but evidence is against you. Just try testing memory pressure on a no swap system. You will see that the system grinds to a half for a few minutes before you even get to an OOM event.

Could you clarify what exactly is "not true"? Also, could you explain what exactly your evidence proves? What do you think happens when the system becomes unresponsive under memory pressure, and why?

> The active code pages are specifically excluded from being discarded during the reclaim process.

This is not true, or the system wouldn't grind to a halt due to having to reload code pages (even those that are recently in use) from disk over and over.

For example, key presses and output streaming in SSH become unresponsive. The code pages for handling key presses and output streaming are obviously in use — I just used them!

I'll try again. Why do you think that unresponsiveness is caused by code pages being discarded? Do you have evidence for this? Have you considered that there are other mechanisms that cause programs to become unresponsive under memory pressure?

It's the explanation that I've read when scouring forums for reasons why it happens. I'd love to hear alternative explanations and how to measure/verify them. But the measurement tools also become unresponsive so I can't check anything.

But frankly, as a user I don't really care what the real technical reason is. I just don't think the system should become unresponsive for minutes on end during memory pressure. Just OOM-kill earlier, when it's supposed to.

The assumption that a system gets unresponsive due to code pages being reclaimed doesn't make any sense. It is a common myth, cargo-cult knowledge. The kernel doesn't discard any active referenced pages at all, and the active code pages are the last that are getting reclaimed.

The proper explanation is relatively straightforward. Normally, any memory request for a process is served by getting a page from the free memory pool. But when the system free memory goes below the low watermark (calculated from vm.min_free_kbytes and vm.watermark_scale_factor), the kernel stops giving the pages from the free memory pool and instead goes into direct reclaim, trying to find unused pages. While the kernel does reclaim, the allocating process remains stalled. The kernel can't return control to the process - there is no page mapped that the process tried to access. This applies to any types of pages - anon, file-backed, code pages. So, under the condition of free memory below the low watermark, any process trying to allocate memory gets stalled. This is measured as memory pressure stalls (PSI) in /proc/pressure/memory.

The problem with the system being stuck in an unresponsive state is that the design choice for the kernel OOM handling is to be optimistic and keep the workload running as long as the kernel is making any progress reclaiming pages. The direct reclaim process needs to fail to make any progress 16 times before the OOM killer is invoked.

The solution is to use cgroup memory limits to avoid getting into the situation of memory exhaustion and use user-space oomd to recover from this situation earlier.

So you're saying processes are stuck for minutes on end at trying to get memory from the kernel? I find this implausible because relatively simple processes such as ssh and bash shouldn't be getting memory from the kernel at a continuous basis. Unless they're suddenly processing a lot of new data (like me trying to cat /dev/urandom), they should be spending most of the time working with the memory they already have. Especially when all I'm doing is pressing keystrokes in ssh+bash, not even hitting enter. Note that malloc doesn't ask memory from the kernel at every call. Glibc malloc is (in)famously stubborn with caching memory it has gotten from the kernel, hesitant to release it back to the kernel.

Any repeatable way to prove your thesis or disprove the trashing-code-pages thesis?

You seem to confuse user-space memory allocations (malloc) with the kernel memory page allocation and mapping. The processes don't need to allocate any new memory with malloc. They get stuck when accessing memory that is not mapped to a physical memory page or when they enter a syscall that needs in-kernel memory allocation.

Ok fine. But again: any repeatable way to prove your thesis or disprove the trashing-code-pages thesis? And how to do this when the system is freezing up?

I have already pointed you to /proc/pressure/memory. Prometheus node_exporter tracks it as node_pressure_memory_waiting_seconds_total and node_pressure_memory_stalled_seconds_total. You'll see them spiking when you experience stalling.

You can also track variables from /proc/vmstat exported as node_vmstat_allocstall_(normal|dma32|movable), node_vmstat_pgscan_direct, node_vmstat_pgsteal_direct - you'll see them spike when the system enters direct reclaim.

Install and configure systemd-oomd and track its log - it will activate on memory pressure.

To track code page eviction/re-faults specifically, you'll need to write some eBPF code, there are no direct measurements for this available.

Perhaps I wasn't clear, but I did say that all file pages are treated equally. I would assume that page with PC is excluded from reclamation process, but other code pages are valid targets.

All code pages in the active file LRU are excluded from the reclaim.

All recently referenced code pages in the active LRU are excluded from reclaim.

Code pages are paged in on demand: for any sufficiently large binary just some code pages will be mapped right after start. Given enough memory pressure, the active LRU will be shrunk often enough to push code pages out of the active LRU and then they are eventually evicted.

I'm not aware how it works in modern MGLRU, but I would assume similar ovservable behevior holds.

Active code pages with the "Accessed" bit set are specifically excluded from being moved to inactive LRU when active LRU is being shrunk. Instead, they are moved to the head of the active LRU. All other pages are moved from active LRU to the inactive LRU unconditionally, even if they have the "Accessed" bit set. So, no, the active code pages are not going to be eventually evicted.

I think we are saying the same thing. Active code pages are not evicted; non-active code pages (that is, pages that had not been accessed since last time of active LRU shrinking) may be evicted.

Under memory pressure the system will free the ram used for code pages because it can always load them back from the executable on disk. It’s the same virtual memory mechanism as swap but without needing dedicated swap space. The op is saying disabling swap doesn’t prevent long pauses during memory pressure, because the system just swaps code out instead of dynamically allocated memory.

There are good sibling replies answering your question, but to give a specific example: if your application writes something but then doesn't need it anymore. Since we're talking about go, perhaps a data structure you need also holds a reference to data you don't need.

When the kernel needs memory, it goes hunting for a page it can discard. But since that's transparent, the kernel can only discard a page if it knows it can get it back (after all, it's still got valid data on it, and maybe you'll try access it again later).

If there's swap, a page full of stale/unneeded data can be written out to swap. But if there's no swap, your page of "dangling data that you'll never use, but is still valid & referenced" can't be discarded; the kernel doesn't know you won't want it later, and it can't recreate the page if it throws it away.

So like sibling said, at that point it has to find other pages it can evict from memory, ones that _do_ have somewhere persistent they can be written out to. Pages loaded from binaries on disk satisfy that, so those will get dropped instead.

For JIT languages most of the code is dynamically generated, not available to be loaded back from the disk. Morealso, the allocations do happen at large chucks where the oom_killer also happens, so it's significantly less of an issue.

That doesn't necessarily improve matters. Now any code that gets JIT'd is also going to be permanently pinned in memory too, no matter whether it'll get used again, if you don't have swap.

Under normal conditions the code gets jitted after some use... and the VM is free to deoptimize it when it reaches its max allowed generated cache.

The only code in danger is the one from libraries (e.g. zlib)

Please read the article. The issue was caused by swapped out metadata being read in a critical section, not typical heap traversal shenanigans.

This is not exclusive to GC, any program that reads a rarely accessed piece of memory is vulnerable to this.

Run your process in a cgroup that's set to disallow swap, then. The rest of your system benefits from having swap. This was an easy and safe thing that required minimal convincing to roll out to production at my company.

Plus, it wouldn't necessarily be that hard to selectively mlock the pages accessed in STW critical regions.

It would probably make sense to disable swapping "code" also for non-GC languages (or at least do it as a last resort).

No, do not try to use mlock to avoid swapping, except in very specific scenarios. That way lies madness.

To be more explicit about my advice: disable swap and ensure you have sufficient memory for your workload.

Your 14 MB Go binary is not the source of your memory pressure. Your memory pressure is coming from the allocated anonymous pages supporting your programs data structures on the heap.

Have sufficient memory for your workload, monitor it, and let the Go GC and kernel manage memory normally. This will work exactly as you'd hope.

Can you elaborate, why mlock is bad? And how disabling swap is better?

You are correct, that 90MB Go binary is not major memory consumer. But it doesn't matter what is the source of memory pressure. What matters is what kernel do under pressure. If you disable swap, then under memory pressure kernel can only pageout memory mapped files, no matter how small they are. And your code will be paged out.

We're trying to solve a problem: we don't want huge latency spikes caused by swapping memory to disk. The only good solution to that is to have sufficient RAM. It's that simple.

Introducing mlock is operationally annoying and trying to solve the wrong problem. It requires elevated container permissions, it's not something your SRE team is going to expect, few programs do it, and it has all kinds of technical implications and interactions with kernel OOM system, forking, the Go GC, etc.

And nothing about mlock solves the problem of having insufficient RAM for your workload.

There are very specific scenarios where mlock is exactly the right solution but the typical Go HTTP service is not one of them. The KISS principle applies.

Using mlock on all the code and static pages in a binary at startup is not hard or risky.

I didn't claim it was hard or risky.

Have you actually done this yourself for Go programs that you've deployed into production? If so, what were the circumstances? Was it your solution to latency spikes?

I am struggling to understand which specific problems that pertain to the use of mlock(2) you are alluding to.

Java is an example of the most widely deployed garbage-collected language in production around the world, deployment number and scale-wise. Most of the world's missing critical systems today run on Java. Java can run as a process or in a container. Containerised Java deployments do not require unique operational SRE arrangements, nor do they require any unique/dedicated permissions to run in a container.

Upon start-up, the JVM checks whether the system has sufficient memory to satisfy the max heap size constraint, and it will duly fail to start up if not. Afterwards, the JVM will allocate the required amount of memory, and it will mlock it. Multi-terabyte[0] RAM JVM deployments[1] do exist and exhibit exactly the same behaviour. Java has had such behaviour since its inception.

The prevailing number of Java deployments run on systems with swap enabled, and, from the operational standpoint, it is pure insanity to run mission critical (banking, payments, government etc) apps without a swap. Swapless JVM deployments are virtually unknown or are operational negligence.

The principal exceptions for running a JVM on a system without a swap are hard real-time scenarios and embedded systems. That is it.

What makes Go different or unique that it can't use mlock and that it would require special permissions or unique/distinct SRE/operational arrangements? It is eluding me.

[0] The Azul JVM supports up to 20 Tb of RAM which it will mlock.

[1] See the published Azul/Forrester evidence for reference. It is an interesting read regardless of the mlock debate.

I'm pretty sure almost all of our (very large) java systems were running without swap (it took effort to enable swap for your jobs, and eventually was almost impossible).

Java is generally simpler to run without swap since you know in advance how large the heap can be, so it's just a small amount of variability in the jvm internals to consider.

You don't want swap of heap/stack, or paged out code pages. The latency hit is pretty bad even for non-"real"-time systems. And really, you should know how much memory you are going to use (to within some fair bounds).

Adding only a small amount of swap for very cold pages does not save very much ram. And using it for anything else is very bad for interactive systems. In the same vein paging out code pages you won't ever run just does not save very much.

It requires some discipline in monitoring, load testing, etc, but you should be doing that anyway.

It was the default for every production binary. I read the c++ implementation, not really that crazy. It was for latency, and in some cases (with other measures) to keep the binary running if the disk failed.

The alternative (which I’ve also done), is to put the binary in tmpfs, after making sure it’s not bloated.

Your Go binary was being swapped out due to memory pressure, causing latency, and using mlock was your fix for this problem?

Or did someone else do this work and you assumed it was effective? Or did you personally implement this change and then validate that the before/after metrics improved as a result?

As I mentioned, it had long been the standard, the core library gave you a simple flag to use. I would occasionally find cases where it was not set correctly and you could see it causing short spikes (the simplest way to measure is something like a pacemaker task on an event loop, or task scheduling delay since it strips out other variables).

The impact is pretty obvious.

Alright, so you didn't implement it. And you're describing a "pacemaker task on an event loop"? That doesn't sound like a Go program at all, where we don't have a single event loop to measure and we have built-in runtime metrics.

Just seems kinda weird to give advice on forums when you're not speaking from actual relevant experience. I'm getting meat proxy answers and confident replies from people who've never done what they're suggesting others do.

As I said, I was more familiar with the C++ implementation, but we had it for every language in use.

I ultimately change the runtime environment to no longer allow any local durable storage for job (with a handful of exceptions), including swap and binary staging. The fact that almost everything was already using mlock made the transition simpler.

You are correct, of course: if your application needs 2x RAM and you only have 1x, then there is no way mlock can magically save you from swapping. What it gives is protection from a noisy neighbour.

The good thing is that mlock/mlockall does not require elevated permissions. But it is bounded by the memlock rlimit, which you need to configure for the container. If you don't want paging/swapping, set it equal to the total memory you give to the container and call it a day.

I'm curious about the technical implications. Which ones do you have in mind?

To be honest, I don't quite see how mlock makes it complex. It's quite the opposite: it has very clear semantics and makes reasoning about system behavior simple. Disabling swap is the opposite: you're making a bet and hoping it works.

In simple cases, instead of using `mlock` just set cgroup memory.min

That would work reasonably well. With one important caveat: memory controller tracks all memory, including page cache. Setting memory.min will prevent reclaim of page cache charged to that cgroup, as long as total memory usage stays below the limit.

Another important caveat: people keep assuming that page cache can be easily discarded and it doesn't count towards the working memory set. Then they get surprised by unexpected OOMs. There is a decade-old issue on Kubernetes https://github.com/kubernetes/kubernetes/issues/43916

Fun fact: being able to run garbage-collected languages (i. e. Lisp) was one of original motivations for adopting demand paging.

And you're probably more productive than the people using Pi. Although you'd be even better off using a GUI agent multiplexer of some kind rather than juggling terminal tabs.

I love open source. I love the terminal. I spent the last 20+ years in a terminal w/vim every single day, and then claude/codex TUIs, and yet I care more about my own productivity so I don't use any of that now.

There's something about this take that... irks me. A little bit more every time I hear it, and I've been hearing it a lot. I dislike the implication that anyone who takes more care with their setup than downloading an exe from a website and double clicking it is some kind of chump. They could be prompting the next ticket instead!

Even if taking pride in your tools was a productivity killer (I have my doubts), maybe there's mental value to be gained.

What do you suggest for a GUI agent multiplexer?

The important thing is just to a GUI agent multiplexer, they're all mostly doing the same kind of thing. IMHO it's very important to have the official claude and codex harnesses (not just models). I also like having each session in a isolated container (or VM) so the agent can go wild and run in yolo mode.

I usually recommend Conductor to most people. Personally, I use the one I built, but it's got a few ergonomic issues for most people which I still need to fix.

onorca.dev. I used herdr before now Orca has fully replaced it. (I'm not affilianted with Orca in any way except I use it every day). Orca also supports separate hosts. My setup Orca running in my Mac. Orca running in my home proxmox lxc (orcabox). I have few different projects, Rails, PHP, etc. In Orca, I open these projects and point it to my local folder as well as the folder remotely.

I usually start a codex or claude session on the remote host, close my mac, even restart Orca desktop on mac, but when I start Orca, I can watch the Orca on my remote host working through.

It's similar to Claude remote session, but just easier to manage, easier to create worktree, easier to navigate, open multiple tabs etc.

Paseo allows you to start a daemon from command line, thereby passing your ENV credentials to the daemon from, say, your 1Password-based env. Then both local Mac GUI and their native iPhone app (through Tailscale) can connect to this daemon. This is the most ergonomic local and remote setup where I can start a session on my Mac and continue on my phone or vice versa, with any agent: Pi, Claude, Codex, OMP, all natively supported.

No affiliation, just arrived at Paseo after a bunch of research.

you can just roll your own, this is probably the most popular side project of the past year, I crafted my own version within a day or so this past week, with corny visual assets as well since its just for me. Kinda rolled my workflows into it so it fits how i work with plans and how i avoid compaction in favor of handoffs or just plan docs that constrain each session to x amount of tokens each session.

Tossed all my weekly usage for each provider at the top with their 5hour windows and such. its been great so far.

Yeah I also created my own TUI one and only took a couple days. Using it less now though because the models have gotten pretty good at spinning up their own agents.

I like Orca

zed.dev is like Orca, but lightning fast and fully multi-player (both AI and humans)

t3.codes

cursor.com

conductor.build

code.visualstudio.com w/ Claude Plugin or equivalent plugin

zed.dev

there are dozens tbh

thats not a suggestion.

none of these are multiplexers

Not sure what "multiplexer" means in this context but Zed allows to switch between agents thread with a side panel and that works very well

It's not an either/or. Orca is a GUI agent multiplexer that works with dozens of harnesses, including Pi. The advantage with Pi is that you can vibe code any kind of extension you want. I like to see various stats (tps, ttft, etc) on each turn, and there's an extension for that, but it doesn't show wall clock time for the turn. Ok, pull down the extension and tweak it to add that. It's great.

vim/past vim terminal dweller here.

I've eventually settled on a CLI agent multiplexer that essentially run in the background while the frontend is a GUI gateway agent to that backend system with a goal middle layer so I no longer need to interject directly into the prompts and forces the CC and Codexes to communicate to me in a structured format relevant to my purpose.

If you like the terminal I'm building https://alcubi.ai/delegator/ It's terminal based and I've taken a different approach to avoid context overload of switching tabs. Agents run in the background and you review the work when it's ready.

What do you use

Personally I use gh copilot in vscode and make new worktrees when I want parallel agents that are both going to write code.

For research, planning, figuring out bugs, etc I usually don’t bother creating the worktree until I’ve decided on the implementation.

I’m sure there’s better workflows and software, but all I’ve got for work is gh copilot and Claude enterprise. I like copilot better than Claude for the most part.

I was under the impression that GitHub Copilot was much more expensive because you're always paying API rates?

Enterprise pays API rates everywhere afaik. Our Claude Enterprise is pay per token too. Maybe some volume deal idk.

it's expensive as hell

what advantage do you have with a gui multiplexer over the terminal?

You can burn a lot more tokens very quickly for the illusion of increased productivity ;-)

“There are no real experts on this” lol yes, Jacob, because there are no “real” soothsayer experts.

It's very possible to predict that certain technologies will be created. It's just very difficult to predict precisely when.

For example, humans will almost certainly be able to re-create the human brain in some kind of hardware+software computer. We just don't know when. It might be much sooner or much later than you'd expect.

Merely being skeptical of progress isn't a convincing answer to the AI x-risk argument.

> An LLM would have done exactly what I wanted back then. But would it have given me what I needed? At the time, I needed to know somebody cared enough to help me.

Were StackOverflow, Google, and LLMs not all created by people who cared enough to help you?

There are much better places on the internet to find personal connection than StackOverflow ever was.

Not really?

They may have cared about helping "people", but not the individual D. (from the OP) who posted a single question and needed a bit of human connection in the process.

Assuming OP is a people, they're included, but I get your point.

And it's great they did find personal connection on Stack Overflow, but it was infamous for its hostility to noobs. It's sad to say, but Stack Overflow very possibly discouraged more people than it encouraged in this way.

I'd guess that both IRC and Discord have a much better track record of personal connection and helping people, and they're still thriving.

Indeed, I was not trying to defend SO, but their point.

Most communities like this develop some (lot of?) elitism, but if you are in the in-group — or early — it can be very rewarding.

My online hacker community time was well before SO (forums even before phpBB, IRC, mailing lists, free software on their self-hosted infra like Gnome, FreeDesktop etc), but you could see the same patterns always (even if you go through usenet group archives or BBS archives).

The beauty of online is that you could always find a community to be in-group of (sounds like a lot of that is happening on Discord these days, but I do not have an account really).

Similarly, you can see that on HN too (passing comments on "green usernames" etc), but it feels like both in-group self-moderation (with flagging and downvotes) and active moderation by dang and co at least keeps it low profile.

Personally, I'd like to hear the full pitch, and I suspect many others would too. If the ideas are interesting enough for you to dedicate the next N years of your life to, I'm probably willing to spend 10 minutes reading the blog post. Particularly from you, a known-good writer.

I’m already edging in the article’s direction on my desktop. I recognised a lot of this, and it makes a great deal of sense.

The only question is if it’ll still make sense in six months, or if an even more unreasonable approach will be the correct one. Feels like a singularity.

Sounds like "secure phone for mass vibeware." Probably containers, authentication, auto analysis, protected user data, etc. Just diff enough from apple/andr that it can't be slapped in overnight.

Testing something, can you guys post useless replies like "cool man" or "...okay?"

Way to go, Ace!

cool man

...okay?

God, your conscience, it’s all the same.

It definitely is not. You’ll find that people that call it God never put it into question as one would their conscience.

Few things are as indicative of mental instability than someone believing God is speaking to them directly. The schizophrenic ward is full of these.

Christians believe that God has called them to live with concern for others, as he has loved them counter-conditionally. When they fail to do so, (everyone does!) on reflection they feel pangs on their conscience. So, on occasion they examine how they are impacting others and if they believe they are doing harm, they change their mind, resolving to avoid the error in the future. They often credit God with the inspiration (the language you keyed in on) because reflection and concern and changes of mind are all his design. You can argue with them: that’s just “doing theology”.