da-x

Smart money is sent to the regions of the world where it creates the most value, it's simple as that.

Specifications are important.

The better the specs of a commercial product, the easier it would be to produce an open source version it, with coding and testing automation perhaps even a one-to-one offering.

Perhaps compacting the context can be made in multiple requests over smaller and overlapping chunks to avoid using the 'dumb zone', and for yielding a better result.

Curious enough, I tried the same prompt with Qwen3.6-27B.

One shot produced a game with no sheeps. I had to told it to fix two bugs then.

Overall, the graphics and games seems good enough and better than most of the closed models that were shown. However, not surprisingly, falls short of Fable.

I've put the index.html and open code session here:

https://github.com/da-x/when-ai-fails/tree/qwen3.6-27b/shepa...

I'm not following this argument. I think there's no real reliability difference between having SHA256-verified dependencies by lock file and vendoring the same dependencies into the codebase. If there's a concern with crates.io availability partial local mirroring is possible.

I wonder what additional kind of software will flag themselves in the future as 'algorithmic', or no-AI. And what kind of non-software services will flag themselves as such.

Nice infographics, but they have not factored in the quite significant income coming from Google and Anthropic deals (around ~$2.8B per month IIRC).

AFAIK Michael Burry is shorting it via PUT options ­­— can look into what he is doing.

I want to own it because I'm pro-Musk and already own much TSLA, but... with so much conflicting commentary from pundits ("It's a scam!" / "It's going to multiple $10T in a decade" / "Wait for the lockup expiry"), I'll take popcorn and watch from the sidelines and maybe DCA for a few years.

Thanks, but I'm too old to switch - will wait for the Neuralink implant.

I am looking for signs we are at 'peak AI', is this it?

> Elevator achieves performance on par with or better than QEMU's user-mode JIT emulation.

I am not sure what QEMU's JIT is doing (in its userspace wrapper), but I think it has a lot of room to improve.

In 2013 I wrote a x86-64 to aarch64 JIT engine that was able to run what was then Fedora beta aarch64 binaries and rebuild almost the entire aarch64 port of Fedora on a x86_64 Linux. I also made a reverse aarch64 to x86-64 JIT that worked in the same way, and for fun I also showed the two JITs managing to run each other in a loop back fashion: x86-64 -> aarch64 -> x86_64 in the same process.

The JIT I devised did a 1-to-many instruction and CPU state mapping with overhead that was somewhat 2x to 5x slower than what would be expected to native recompiled code. I later compared this with QEMU's JIT which seemed more in the range of 10x to 50x slower.

Unfortunately this was not under a open source license settings, so no code release to prove it.. :(

Since 2022 I have coded something similar for myself, only for Linux for each of my notes, e.g. each and each every small or big task gets its own bundle of things that are attached to its 'task note'.

Each note gets a wholesome 'virtual desktop' "space":

- A markdown file (in a Git repo for all my notes)

- A working directory for project files

- Virtual desktop in hyprland that opens up as a terminal/browser split

- The terminal spawn a restorable tmux session where I edit the markdown file and open related terminals, where the note's workdir has its own `bin` directory in $PATH.

- Also, an ironbar widget showing the name of the current note at the bottom of the screen.

- Time tracking app to remember how much time I worked on each note.

And they are all bundled up together with save/restore capability, kinda like a VM, but on the application level. The idea is to support multitasking and never lose focus.

Third solution is "taxation through inflation" in which the official inflation is 4%, the unofficial one is 10%, interest rates kept low, and over a few decades the debt gets nominally trimmed down against a nominally rising GDP. Real GDP growth will even accelerate this. Owners of assets that are not real-inflation protected (such as the debt owners) see their asset value go down ; people who have no net equity see their salary go up, but only in nominal value ; people who hold real-inflation protected assets that also distribute dividends are the winners in this.

Yes (coLinux author).

What I especially like about this Windows 9x Subsystem project, is that it proves that coLinux could have been written way earlier. Now imagine how less dual booting we would have needed in 1996 if that happened, and how it would have affected VMware which only existed since 1998.

I use Qwen 3.5 122B on an RTX PRO 6000 with open code, and very pleased. I don't feel a need for using a closed model any more. The result after answering questions in Plan mode is almost always what I want, with very few occasional bugs. It does a lot of effort to see how the code I am working on is written now while extending it in the same style.

If they release a Qwen 3.6 that also makes good use of the card, may move to it.

The issue with static recompilation are edge cases such as self modifying code, or code copying a variations of itself to be executed on the stack, jump tables of structure that cannot be inferred from analysis without solving for the halting problem and all sorts of other tricks that necessitate the use of a JIT eventually. I wrote a static recompiler for Win32 in 2012 for fun, and I've seen old 1990's programs do these things.

Yeah, it would be ridiculous that the IRGC terrorist regime, which fired super-inexact ballistic missiles that split to cluster bombs that spread in 70 parts on a 3 miles radius in residential areas, for a whole month, on a daily basis, would ask that someone _else_ will be held go to the ICC tribunal...

[flagged]

Alternative, you can check whether there are duplicates under $PATH resolutions - binaries that can come from more than one place in $PATH.

    #!/usr/bin/env -S cargo eval --
    // cargo-deps: derive-error="0", is_executable="0"
    // vi: ft=rust

    use derive_error::Error;
    use is_executable::IsExecutable;
    use std::collections::{BTreeMap, HashSet, btree_map};
    use std::os::unix::fs::MetadataExt;
    use std::path::{Path, PathBuf};

    #[derive(Debug, Error)]
    pub enum Error {
        VarEnv(std::env::VarError),
        Io(std::io::Error),
    }

    fn main() -> Result<(), Error> {
        let mut paths_seen = HashSet::new();
        let mut path_fileid_seen = HashSet::new();
        let mut exes_seen = BTreeMap::new();

        for path in std::env::var("PATH")?.split(":") {
            let path = PathBuf::from(path);
            if !path.is_dir() {
                continue;
            }
            if !path_fileid_seen.insert(path.metadata()?.ino()) {
                continue;
            }
            if paths_seen.insert(path.clone()) {
                match std::fs::read_dir(&path) {
                    Err(_) => {
                        eprintln!("error listing {:?}", path);
                    }
                    Ok(readdir) => {
                        for entry in readdir {
                            let entry = entry?;
                            if entry.path().is_executable() {
                                let mut item = match exes_seen.entry(
                                    String::from(entry.path().file_name()
                                        .unwrap().to_string_lossy().as_ref()))
                                {
                                    btree_map::Entry::Vacant(v) => v.insert(vec![]),
                                    btree_map::Entry::Occupied(o) => o.into_mut(),
                                };
                                item.push(path.clone());
                            }
                        }
                    }
                }
            }
        }

        for (exe, paths) in exes_seen.into_iter() {
            if paths.len() == 2 {
                let mut strs = vec![];
                for path in paths.iter() {
                    strs.push(path.to_str().unwrap());
                }
                if strs.as_slice() == ["/usr/bin", "/usr/sbin"] {
                    continue;
                }
            }
            if paths.len() > 1 {
                println!("{}: ", exe);
                for path in paths {
                    println!("    {}", path.to_str().unwrap());
                }
                println!("");
            }
        }

        Ok(())
    }

No war in history has completely avoided any civilian casualties or attacks on civilian populations, as even limited conflicts often involve indirect harm (e.g., from stray fire, blockades, or displacement), and larger wars almost inevitably affect non-combatants.

Curious how the concept of the 'war crime' is weaponized by the pacifist and largely ignored by the non-pacifist that knows how proper deescalation can take place.

TDLR: A link to bad short-seller video from 4 years ago and a lot of unsustainable claims.

I wonder didn't they used VDO thin provisioning with LVM2.

Also, a few years ago I've implemented VM management tool called 'vmess', in which the concept is to maintain a tree of QCOW2 files, which R/W snapshots are at the leafs and R/O snapshots are the nodes of the tree. The connection up to the root is made via QCOW2 backing-file store mechanism, so a newly created leaf starts a 0 space. I did this because libvirt+qemu impose various annoying limitations surrounding snapshots-with-in-qcow2, and I liked the idea of file-per-snapshot.

VDO: https://docs.kernel.org/admin-guide/device-mapper/vdo.html (original project URL: https://github.com/dm-vdo/kvdo )

vmess: https://github.com/da-x/vmess

It is very unlikely that Israel will ever withdraw its 500,000 citizens from Judea and Samaria, given the result from the 8,000 citizen withdrawall from Gaza.

An equal territorial exchange is much more realistic, as part of a two-state comprehensive package. However, "63% of Palestinians, 65% of Israeli Jews, and 13% of Israeli Arabs are opposed to this two-state comprehensive package.', see https://pcpsr.org/en/node/989 .

There are various hardware singletons that need to be managed for this to work properly. This raises many questions.

Which of the kernel does the PCI enumeration, for instance, and how it is determined which kernel gets ownership over a PCI device? How about ACPI? Serial ports?

How does this architecture transfers ownership over RAM between each kernel, or is it a fixed configuration? How about NUMA-awareness? (Likely you would want to partition systems so that RAM is along with the CPUs of the same NUMA node).

Looks to me that one kernel would need to be have 'hypervisor'-like behavior in order to divvy up resources to other kernels. I think PVM (https://lwn.net/Articles/963718/) would be a preferred solution in this case, because the software stack of managing hypervisor resources can already be reused with it.

Note that it has one pitfall that is hard to notice: if you a use per-invocation `-o SendEnv`, that gets ignored in favor of the background ssh persistent connection that is keeping the session up. In other words, your connection bear the `SendEnv` of that initial connection and not of the new ones you are creating. No warning is printed.

I dislike flash cards, preferring to answer open questions instead, where you have to fill a word in a sentence. Open questions also prevent rot learning.

LLMs are really good at generating such open questions.

E.g. "The committee was ______ to the proposal, provided that a few minor adjustments were made to address public concerns." - I generated this using a simple prompt. Guess the word that needs to be filled in :)

I'm not sure it's working well.

https://www.alltext.nyc/search?q=linux

There something about this.

I am on my 6th smartphone, it is the first phone of which the screen accumulates scratches. Google Pixel 9. None of my previous phones needed a screen protector.

> Unlike how rpm or apk packages are done, the deb package sources by design avoid having one massive procedural packaging recipe.

I think that one massive recipe of a well documented preprocessed language such as RPM is exactly what makes RPM maintenance a breeze compared to DEB. The inputs and outputs of each stage are clear. The expansion of the macros. The idea that you only need to execute a single command `rpmbuild` and everything is neatly wrapped from underneath it.