here you gooo
MintCraft is a decentralized marketplace where AI generates content (art, music, text, code) that's instantly minted as NFTs on Solana, with built-in ownership tracking and monetization. Users can also register their own AI models and earn from usage fees.
brewing something on solana where you can register your AI bots, users prompt 'em, outputs get minted as NFTs instantly, and listed right there. fast, cheap, mildly unhinged. ai x solana x vibes.
Cloud platforms require CNAME for dynamic routing but a CNAME cannot coexist with other record on the same node you root (https://t.co/UASZFAGxpn) is zone apex requiring SOA, NS records, so CNAME on it breaks
Creating www gives you a subdomain where that CNAME can safely live
www usage today is nothing like why it was created
The www prefix was an administrative convenience and human convention, not a technical requirement of the HTTP protocol
earlier it was pure hardware survival web servers were experimental so sysadmins gave HTTP its own physical box labeled www to isolate it from the company’s core network
Today, it solves an RFC 1034 colliison problem
For silent drops (like network cuts or power failures where no FIN packet is sent), tuning tcp_keepalives_* settings forces the OS to probe the connection
When a client drops its connection to a backend mid-request, the database can end up running wasteful joins and holding heavy locks for a client that isn’t even listening. PostgreSQL handles this gracefully without resorting to unsafe, external SIGTERM kills
If the socket closes gracefully via a TCP FIN, setting client_connection_check_interval instructs the Postgres query executor to actively poll the socket mid-execution. Once detected, CHECK_FOR_INTERRUPTS() triggers an orderly self-cancellation
gVisor is a user-space kernel (Sentry) that intercepts and emulates container system calls, integrated via runsc.
Filesystem access is proxied by Gofer, a sandboxed process holding host FDs via LISAFS IPC. gVisor also processes network traffic via its own stack.
The fix for this is changing the linux sysctl config,
vm.overcommit_memory=2
this will make sure kernel does not promise fake memory and checks the strict limit
when a process calls malloc(),Linux gives it a virtual address space,promising with physical RAM only when pages are written to.
sometimes this leads to overcommit,cause linux promises more RAM than it actually has.
now ,if the Postgres is one of the running process,it is the prime target because it holds a lot of memory and one of many process run by Postgres gets killed by a SIGKILL,now the parent postgres process chooses safety,so it kill all remaining process as well
Asynchronous isn't always faster.
Asynchronous DRAM isn't aligned with the CPU clock
,forcing the CPU to waste cycles
whereas SDRAM aligns transfers directly to clock cycles.
asynchronous only means uncoordinated
Following Round 1 of DisCo, the team just released DiG-bench—a brand-new benchmark testing how SOTA AI models perform on novel discovery games.
The outcome? It’s a massive win for human intuition.
Even inside text-only environments where frontier LLMs (like Opus, GPT, Claude, and Kimi) should theoretically excel, they completely stalled on Tier 6 and Tier 7 puzzles.
Yet, humans solved these exact same puzzles on their very first attempt. I actually managed to crack 10 out of 20 puzzles on my first try and overall around 16 out of 20!
It’s a fascinating look into human reasoning. When it comes to active experimentation, forming hypotheses from scratch, and navigating pure ambiguity, human intuition still far outperforms AI.
Beyond Incentives: Pure Scientific Progress
What makes DisCo so special is its mission. Built by Thinking About Thinking (a non-profit initiative), this platform isn't about commercial product growth. It exists purely to advance neuroscience, human cognition, and scientific discovery.
It brings together scientists, engineers, and competitive problem solvers to map out how intelligence actually works.
Cohort 002 Starts This Wednesday, 12 August!
I am thrilled to announce that I’ve been nominated as a Community Captain for Cohort 002, and I’m assembling my own team—Codehurdle—to take on the next wave of interactive puzzles.
Here is what is on the line:
Prize Pool: $15,000 in overall rewards (individual + community prizes).
Launch: Wednesday, 12 August at 3:00 PM UK time.
Who should join: Anyone who loves unguided problem-solving, testing hypotheses, and flexing their reasoning skills against the best in the world.
We will be competing both individually and as a community. Ready to test your brain against top-tier problem solvers and SOTA AI?
HOW TO ENTER (MANDATORY):
To be eligible to play and win prizes, the organizers require you to:
1. Like and Repost (RT) this post!
2. Apply here to join my team: https://t.co/j1eUTiBPXQ
Let's see how far we can push the human side of the benchmark this round. Join Team Codehurdle today!
— Amartya Singh
#ScientificDiscovery #ArtificialIntelligence #ProblemSolving #CompetitiveProgramming #AIBenchmarks #DisCo #Reasoning #Codehurdle
@SaharshSingh16 @ai_x_man@akshonite @disco_org @who__shivam
Here is something interesting about memory management in Linux: most systems use 4KB pages by default. But, there is something called Transparent Huge Pages (THP) that configures your system to use 2MB pages instead. Here's why it matters...
Every time the CPU needs to translate a virtual address to a physical one, it looks up the page table. This lookup is expensive, so there is a small cache called the Translation Lookaside Buffer that stores recent translations (yes, the one we studied in operating systems).
The problem? TLB is tiny - it can only hold a few hundred entries. So if each page is just 4KB, the TLB can only cache translations for a small slice of memory (128KB to 512KB).
But if each page is 2MB, suddenly the same number of TLB entries can cover 64MB to 256MB, which is 500x more memory accesses cached. Fewer TLB misses mean faster memory access.
When this setting is changed, the applications need not do anything; it is a pure OS setting change.
But here is the catch - THP can hurt database performance. To create these 2MB contiguous pages, the kernel sometimes needs to "compact" memory by shuffling pages around. This can stall your application for hundreds of milliseconds, sometimes even seconds.
Databases like MongoDB, Redis, and MySQL have sparse, random memory access patterns. They do not benefit from huge pages, and the compaction overhead just adds unpredictable latency.
Not only that, but if your application only needs 100KB, a 2MB page still gets allocated. That is 1.9MB wasted. For applications with lots of small, sparse allocations, this adds up quickly.
Also, when the system needs to swap out a huge page, it first has to split it back into 4KB pages. This splitting operation takes time and adds latency during memory pressure.
Even when a process forks, pages are shared until one process writes to them. With huge pages, a single byte write triggers a 2MB copy instead of a 4KB copy.
This is why most databases recommend disabling THP entirely. If you want to check your THP status, you can just fire the command
```
cat /sys/kernel/mm/transparent_hugepage/enabled
```
When I benchmarked it, I saw tremendous results for Spark workloads and Redis with large KV data. But the penalty when data is sparse is actually much worse.
THP is a classic trade-off. So, know your memory access patterns before you decide to turn it on.