devit

Seems a bad idea to call it Sora given that it has nothing to do with OpenAI Sora (other than achieving a similar goal). Also a trademark violation probably.

If you actually want good compression, this is definitely not the proper way to go.

The proper way to go is to compute all available moves on a given position, assign them a probability distribution and then perform arithmetic coding using it.

If you want simplicity, assign an uniform distribution. For optimal compression, use an engine such as Stockfish to evaluate how strong the moves are, and then apply a statistical model that converts move strength to weights to make a probability distribution for; also use an opening books for the openings and tablebases for the endgames.

My wild guess is that it will probably result in something like 3-4 bits per move on average.

If you instead want a simple encoding, then encode in 4 bits the piece that moved based on any order on the chessboard squares, then in 6 bits the destination square for 10 bits per move.

To support copy&paste all you need is a common format for 3D objects, like HTML is for 2D documents; glTF might be a reasonable candidate.

The problem with the Apple approach is that there are no apps and games, and there probably won't be many given it's a 3500$ device with few users that Apple exerts its tyrannical grip over (or if there will be, they will be ports of Unity/Unreal, PC or Android VR apps, not using any of the special features that the Apple OS may have).

It's very easy.

The only issue is that GrapheneOS doesn't provide a built-in way to have root privileges and if you want root on your phone securely you will have to implement that yourself or use some third-party solution (e.g. building a userdebug build, using https://github.com/chriswoope/resign-android-image, using Magisk, etc.).

Android Auto support has been added recently and it seems to work well.

I don't understand this.

It seems that they:

- Fail to properly position glyphs horizontally (they must obviously be aligned to pixels horizontally and not just vertically)

- Fail to use TrueType bytecode instead of the autohinter

- Fail to support subpixel antialiasing

These are standard features that have been there for 20 years and are critical and essential in any non-toy software that renders text.

How come GTK+ is so terrible?

EDIT: they do vertical-only rather than horizonal-only. Same problem, needs to do both.

It would have to be introduced by making it default, so all existing generic items would have Move bound on all generic parameters.

Only in a new edition the default can then be swapped.

Monopoly = you can get a given thing or something equivalent to it only from one producer

- Nintendo Switch hardware only runs Nintendo Switch OS -> Nintendo monopoly on Switch OSes

- Nintendo Switch OS only runs on Nintendo Switch hardware -> Nintendo monopoly on Switch OS hardware

- Nintendo Switch hardware and OS only run officially licensed Nintendo game -> Nintendo monopoly on games for Nintendo Switch and OS games

- Nintendo Switch games only run on Nintendo Switch -> Nintendo monopoly on hardware that runs Switch games

(Apple and iPhone are in the same situation)

Compare to the situation with Windows:

- x86 hardware can run any OS, including Linux and Windows -> mostly no Microsoft monopoly, although Windows and Microsoft keys are often pre-installed

- Windows can run on any x86 hardware (and ARM I think?) -> no Microsoft monopoly, although they don't release source to port to other CPU architectures

- Windows can run any software from anyone at no charge -> mostly no Microsoft monopoly, although they can favor their own software

- Windows software can run on any OS, such as Windows or Linux with Wine -> mostly no Microsoft monopoly, although one can argue that having an OS API without an open-source implementation induces lock-in and creates a partial monopoly

This is very interesting when applied to thoughts and interiorized beliefs, as well as belief systems that purport to free you from those thoughts and beliefs.

I think the conjecture is that each expert of GPT-4 has 220B parameters, for a total of 1.76T parameters.

How is this possible?

GPT-4 is supposed to be 8*220B = 1.7T parameters, so it seems unexpected that a 70B model can beat or match it unless it's somehow a much better algorithm or has much better data.

That's the same length. There is also "mov dil, 42".

Note that the assembly code is suboptimal, since it wastes 4 bytes for each immediate.

The optimal assembly code is this: "mov al, 42; xchg edi, eax; mov al, 60; syscall". Or just "mov al, 60; syscall" if you want to exit with 0 rather 42.

Well, because any specific outcome from sampling a random distribution is indeed very unlikely.

In practice, that means that if you have an alternate "non-random" or "less random" explanation for the data, you'll be convinced that it's almost surely the correct one after just a few samples (via the obvious Bayesian decision framework, or just "common sense").

For example, imagine that you are rolling a die and 3 always comes up. On every roll, the likelihood of the die being a fair random die (as opposed to a loaded die) is divided by the number of sides, so with a 6-sided die, you'll usually be convinced that it's loaded after just 3-20 times of giving the same result (depending on your prior on it being loaded vs fair and your decision threshold).

Likewise, if only 1 and 2 come up you'll quickly be convinced that it's an unusual die that only has 1 and 2 symbols on the face.

Or another way to look at it is that processes are usually not random at all (rather they are usually deterministic, but the initial state is unknown) so a random distribution is a very bad model, and having any information about the initial state at all will drastically increase the likelihood and thus make the model with information strongly preferred; the likelihood of the random model is so low because that model is very bad, even though it may be the best available.

I think he's referring to the fact that you can sideload apps as well as run most most smartphone Android apps on the Quest, and also use it as a PC headset.

Committed relationships found by judging other people's personality and looks are completely unnatural for human beings, and a result of conditioning by society.

The natural state is living immersed in a place where other beings are and spontaneously interacting with them without a developed ego/personality filtering the interaction, as the closest relatives to human (chimpanzees and bonobos) do.

This makes the socially-conditioned relationship model very unstable, since such a relationship will only work if, as long as and to the extent that the conditioned beliefs happen to match the other person and their beliefs.

Since the conditioned beliefs are fundamentally false (because they are of the form "you will be happy if X" but happiness is actually the absence of any such belief) they are unstable and they will mutate once their falsehood is partially realized, and this process, along with viral cultural propagation, also creates many different conditioned mindsets that make matching and intimacy very challenging.

So the problems with dating apps are just a very specific effect of what is the fundamental nature of human beings and reality.

Rust uses all zero-cost abstractions except for bounds checking and integer overflow checking, so no language can be faster than Rust (assuming equal quality implementations) unless it either isn't memory safe or it can statically prove bounds more frequently, which pretty much requires dependent types (but current languages with dependent types box everything AFAIK so they are terrible performance-wise).

Mojo seems to not only not lack dependent types but also lack first-class references with lifetimes and no lifetime kind, only having borrowed function arguments.

So the answer is no, it is going to be slower since some patterns cannot be expressed and would require costly abstractions.

For example, it looks like that in Mojo an hash table lookup requires to copy the value, while Rust just returns a reference to the value inside the hash table, which it can do since it can express that the return value has the same lifetime as the self parameter because Rust has first-class lifetimes and references (although in this case they can be elided).

I can't understand the article.

If you want to encode video, use ffmpeg. Netflix serves static movies, so encoding is going to be relatively rare and can probably be done on whatever computing resources are already available. Quality-wise, the ffmpeg/x264/x265 people probably are doing a good job already.

If you want to serve video, serve it with HLS or similar from static files stored on a CDN with a bunch of bitrate profiles. Here the problem is more creating or finding the CDN that anything to do with video.

Can't quite figure out what the purpose of all the stuff in the article could be (maybe to justify the jobs of the people doing the work?)

I think it would be really nice to have a "strict mode" (for app testing), where PostgreSQL returns an error if an index would improve the query asymptotically and it doesn't exist (only based on the query itself, not statistics).

And a "CREATE INDICES FOR <sql>" command to create the indices (for app upgrades), plus an automatic index creation mode (for interactive and development use).

In general, the system should be architected so that asymptotically suboptimal execution never happens.

Maybe they could test it on "tricky" positions where increasing the search depth on Stockfish dramatically changes the evaluation.

They could consider dropping Gecko in favor of Blink, which would save a lot of engineering resources that could be used to implement features instead of web compatibility, and would effectively guarantee that Firefox will be always strictly better than Chrome (since it would be Chrome minus the Google antifeatures plus the Mozilla features).

Has anyone successfully bypassed the region lock? What does it check exactly?

Does it need a US credit card? A US IP address? A Google account with a US phone? A Google account created from a US IP address? Some other way of tying the Google account to a country?

Seems like it could also be Waymo going straight north, truck going straight south and bike going straight east passing just behind the truck (or rotations of this), since there seems to be just stop signs at the intersection.

They could make it a condition of doing business in the EU (which of course leaves Apple the option of pulling out from the EU).

Not clear though whether they have any interest in doing that.

Anything statically linked to the C library will also have direct syscalls in the binary.

GrapheneOS with sandboxed Play Services seems unaffected.

The Phone app doesn't seem to be able to view or open web URLs in contacts, and the Contacts app fails to open the two URLs given in the article in pinned mode.

It seems that a lot of basic information is missing in the review:

1. How does it compare to an high-end monitor for text editing/programming, web browsing, watching non-VR video, playing non-VR games? Is it better or not?

2. Is the resolution, latency, FoV and lack of color fringing good enough for it to be indistinguishable from reality in both passthrough and VR modes? If not, how exactly far is it?

3. Can you run VR games on a PC with multiple desktop GPUs and stream to it? How does it compare to current high-end and ultra-high-end VR headsets?

Why does this have a cost?

You can get street view images from maps.google.com for free, so a scraper should be able to use the same interface for free (as long as it's either not throttled, or you can get multiple IPs or don't care about speed).

"that a simple system does not have to require endless setup and customization to be practical" and "alternative userland" don't go together since obviously any "alternative userland" is going to break lots of stuff and thus require extensive tweaking work.