devit

Where's the performance on common useful tasks?

What's the largest number it can factor using Shor's algorithm? What's the largest hash it can compute a pre-image for using Grover's algorithm?

Well, most non-surgeon doctors are already of limited use since for "easy" things information on the web is good enough or better and for "complex" things that need a lot of research the issue might be unsolvable and if it is you usually need to do the research yourself (unless you can find and hire a doctor that is actually willing to research your case for hours), so they are only useful for "medium" difficulty issues that aren't easily diagnosed by just tests but can be relatively quickly diagnosed by someone experienced.

I think this works.

You can buy two small dishwashers, keep clean stuff in one, dirty in the other, then run the dirty one and swap.

Or you can also just have one plate and wash it by hand after every meal.

Why not use GraphQL instead of inventing a whole new protocol?

Why is live a lot harder?

Aside from latency (which isn't much of a problem unless you are competing with TV or some other distribution system), it seems easier than on-demand, since you send the same data to everyone and don't need to handle having a potentially huge library in all datacenters (you have to distribute the data, but that's just like having an extra few users per server).

My guess is that the problem was simply that the number of people viewing Netflix at once in the US was much larger than usual and higher than what they could scale too, or alternatively a software bug was triggered.

It seems obvious to me that Common Crawl plus Github public repositories have more than an enough data to train an AI that is as good as any programmer (at tasks not requiring knowledge of non-public codebases or non-public domain knowledge).

So the problem is more in the algorithm.

Wouldn't dead reckoning with the accelerometer and gyroscope in addition to their machine learning improve this significantly? (constraining motion along the known tunnel path when in a moving train, constraining the user to be within the train stopping rectangle when detecting a train starting to move)

Or is the hardware in smartphones too inaccurate even with the extra information?

I like the way it works, and I'm experimenting with customizing Firefox to behave like browser.horse.

Currently I did this, which seems to completely mimic what they show in the video:

1. Install Tree Style Tabs. This will give you hierarchical tabs in the sidebar

2. Install Simple Tab Groups. This will let you create multiple separate "tab groups" (aka workspaces) with different sets of tabs.

3. Go to Settings, turn on "Open previous tabs and windows" in General/Startup. This will make Firefox reload your tabs on startup

4. In about:config set browser.tabs.unloadOnLowMemory to true. This will make the browser auto-unload unused tabs so you can have unlimited tabs without running out of memory.

5. In about:config set browser.search.openintab to true. This will make the search bar open search results in a new tab

6. In Tree Style Tabs config set "Promote All Children to parent level always". This will make closing intermediate tabs in the tree work properly (remove the intermediate and reparent all children to the intermediate parent).

7. Install Tampermonkey and add the userscript at the bottom. This will remap click to open a new foreground tab (i.e. original ctrl+shift+click), shift+click to navigate in the current page (i.e. original click) and ctrl+shift+click or shift+middle click to open in a new window (i.e. original shift+click).

Note that the extensions require privileges to access data on all sites, so make sure you trust them or do this on a separate profile or VM.

Compared to browser.horse, this is free and customizable, but might be less optimized, perhaps less featureful and won't automatically get any new feature the browser.horse developers invent.

    // ==UserScript==
    // @name         Click opens in new foreground tab
    // @namespace    http://tampermonkey.net/
    // @version      2024-11-12
    // @description  Click opens in new foreground tab
    // @author       You
    // @match        *://*/\*
    // @grant        none
    // ==/UserScript==

    (function() {
    'use strict';

    function generateRandomId(length) {
        const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
        let result = '';
        for (let i = 0; i < length; i++) {
            result += characters.charAt(Math.floor(Math.random() * characters.length));
        }
        return result;
    }

    const eventProp = "customClick_" + generateRandomId(32);

    function customClickHandler(event) {
        if (event[eventProp]) {
            //console.log("customClick: recursion " + event);
            return;
        } else {
            //console.log("customClick: first " + event);
        }
        const ctrl = event.button === 1 || (event.ctrlKey && event.button === 0);
        const shift = event.shiftKey;

        let newCtrl = undefined;
        let newShift = undefined;

        //console.log("customClick: detected with " + ctrl + " " + shift);
        if (shift && !ctrl) {
            newCtrl = false;
            newShift = false;
        } else if (shift && ctrl) {
            newCtrl = false;
            newShift = true;
        } else if (!shift && !ctrl) {
            newCtrl = true;
            newShift = true;
        } else { // !shift && ctrl
            return;
        }
        //console.log("customClick: dispatching " + newCtrl + " " + newShift);
        const options = {};
        let source = event;
        while(source) {
            for (const prop of Object.getOwnPropertyNames(source)) {
                options[prop] = event[prop];
            }
            source = Object.getPrototypeOf(source);
        }
        options.button = 0;
        options.ctrlKey = newCtrl;
        options.shiftKey = newShift;

        let newEvent = new PointerEvent('click', options);
        newEvent[eventProp] = true;

        event.preventDefault();
        event.stopPropagation();
        event.target.dispatchEvent(newEvent);
    }
    document.addEventListener('click', customClickHandler, true);
    document.addEventListener('auxclick', customClickHandler, true);
    })();

Doesn't seem fractal: the dots on the door become big as the camera approaches it rather than revealing underlying fine-grained structure.

It looks like none of the proposed approaches work well, and the problem seems to be much more complicated that it looks.

I think what might work properly is:

- A "fractal" dither pattern so that it can be zoomed out and in smoothly and is scale invariant

- Doing things in texel space so that both camera movement and object movement works properly

- Doing bilinear filtering (perhaps keeping all samples instead of storing the weighted average) or perhaps supersampled rendering of the dithered pattern, and then using some sort of error diffusion pass in screen space (with a compute shader)

But not actually sure if this works in practice.

If that's not enough, an alternative would be to do things in screen space "naively", then reverse map the screen space rendering to texel space (in a resolution-preserving way), and use the information in texel space on the next frame to create a screen space solution compatible to the one in texel space, map it to texel space, etc., effectively building up the fractal per-texel pattern incrementally at runtime. This might be the best solution but seems very expensive in terms of memory, computation and complexity.

Presumably those services use Chromium codecs and perhaps standard WebRTC, so they have access to the encoded data stream as well (via JavaScript injection or patching Chromium to dump the data).

The problem seems to be that they are decompressing video in Chromium and then sending the uncompressed video somewhere else.

A more reasonable approach would be to have Chromium save the original compressed video to disk, and then use ffmpeg or similar to reencode if needed.

Even better not use Chromium at all.

It's an approximation, but if you don't do that, someone creating and updating a container in a loop (or intentionally running wget in a loop) will skew the statistics arbitrarily.

I don't think there is a more precise way to do it without compromising privacy. Obviously if you are willing to compromise privacy you can send information such as whether the distribution is running in a container or VM and the NIC MAC address and a persistent identifier, but that would be unacceptable since it is not in the interests of users to send that.

Presumably they can use Cloudflare or similar for free or relatively cheap, or perhaps find someone willing to gift CDN service to a Linux distribution.

Redirecting the requests to the closest existing mirror also obviously drastically reduces bandwidth requirements and should presumably be doable with a few (for redundancy) colocated dedicated servers running efficient server software.

They can host all the default mirrors themselves, either by serving the actual data (with a CDN) or by redirecting requests to a 3rd party mirror by GeoIP.

They and can should count users only by updates.

Make a package that is required and only changed upon each release (containing for instance /etc/os-release) and count how many distinct IP addresses download it.

The reason is that most developers have no clue and/or no interest about performance, and so they only optimize where there's a user-visible problem, which means that the program will consume resources proportional to speed of the developer's machine.

That's not a regular expression and it's a ridiculously inefficient way to check for primality.

Seems to me a more reasonable threshold would be at most 10^-9 probability of the conclusion being false (in the Bayesian sense of course), with the prior chosen by the editor and reviewers (and the models being selected upon also being agreeable to them).

What about people who, with their current habits, are on the bottom range of what is considered "normal" weight (in the BMI sense) or already underweight?

Wouldn't taking GLP-1 agonists (for potential non-weight-loss benefits) be potentially harmful as it may reduce eating even further and lead to being significantly underweight?

That's obviously impossible since it would break backward compatibility and the users' existing filesystems (and the Linux kernel will rightly never accept anything like that).

The only reasonable fix is to enhance bash and shell IDEs to track for each variable whether it could possibly include all filename-valid characters (e.g. if it comes from read with no options then it can't contain \n) and warn (off by default unless stderr is a terminal) if they can't and it's used as a filename (conservatively determined when used as arguments to processes), and also warn when using find without -print0, etc. noninteractively and perhaps interactively as well.

A* with a consistent heuristic is Dijkstra on a modified graph whose edge weights are the original edge weights plus f(target) - f(source) where f is the A* "heuristic".

If the heuristic is not consistent, the edge weights aren't necessarily nonnegative, but you can still use the "hybrid Bellman–Ford–Dijkstra algorithm", which is a generalization of Dijkstra that works for all graphs, and should be asymptotically better than naive A*.

That would involve a 100x slowdown in most cases, without dynamic code generation.

It's much better to compile multiple versions of the code or multiple binaries.

Also, any OS kernel could do transparent emulation like that with no need for CPU assistance (beyond trapping on unsupported instructions, which all modern ISAs of course already do), so it's more of a Linux/Windows ABI issue. You can also write an LD_PRELOAD library that does the emulation.

Surely it could just insert the proper form depending on context? (with language-specific code of course)

Not clear how this Wikipedia article survived deletion, given that while the society seems to actually exist the subject is clearly not notable (memberships are sent without request or consent) and the article is plainly not NPOV and misleading, presumably written as a joke or as a proof-of-concept of an attack on Wikipedia.

The advantage of a van is that intra-continent travel becomes trivial.

There's no need to plan anything or prepare baggage or get used to sleeping in different places or pay anyone or deal with any businesses or setup camping gear: you just input the destination in the satellite navigator, drive there and can go to sleep as usual at any time (and potentially you can even find on BlaBlaCar/similar someone willing to drive the van for you in exchange for a free ride).

The C library uses macros so that the referenced symbols are different depending on ABI (e.g. open becomes open64, etc.), but most 3rd party libraries don't bother with that, so they break if their API uses time_t/off_t.

You can make the struct generic on the type to have a field being an impl Trait type.

I wonder why they did this, thus revealing that they compromised a lot of devices and losing that capability, instead of quietly continuing to monitor them and using their location to perform attacks via other means if needed.

Maybe they hope the psychological effect is a big deterrent?

What?

They say: "ARC-AGI tasks are a series of three to five input and output tasks followed by a final task with only the input listed. Each task tests the utilization of a specific learned skill based on a minimal number of cognitive priors.

Tasks are represented as JSON lists of integers. These JSON objects can also be represented visually as a grid of colors using an ARC-AGI task viewer.

A successful submission is a pixel-perfect description (color and position) of the final task's output."

As far as I can tell, they are asking to reproduce exactly the final task's output.