0x76's comments

On: PSD is not my favourite file format

[0x76]

Why is the link to a seemingly unrelated blog instead of to the actual source?

[skrebbel → 0x76]

A total guess, but maybe because it renders better on mobile?

[ducaale → 0x76]

I should have thought this through before linking to a self-hosted site [1]

[1] https://b3n.org/about/

On: Revision demoparty banned on Twitch mid-stream

[0x76]

Isn't that what Mixer did, and failed?

[sen → 0x76]

Among others. It’s easy to beat twitch from a comment section, but well funded companies have tried and failed.

On: Signal is having technical difficulties

[0x76]

I thought that it just sends push notifications without content which then wake up the app so that the app itself can fetch the message from your homeserver with encryption

On: Worlds First $150 RISC-V based PC

[0x76]

Duplicate of: https://news.ycombinator.com/item?id=25761469

On: Atomic Typos (2005)

[0x76]

It isn't nicknamed disk destroyer without reason

On: Lua in the Kernel?

[0x76]

You can't prevent infinite loops unless you've solved the halting problem right?

They could of course just limit the run time if they really wanted to make sure scripts don't run indefinitely.

[coldtea → 0x76]

>You can't prevent infinite loops unless you've solved the halting problem right?

Only in general arbitrary turing complete runtimes. For restricted subsets of instructions and specific implementations of runtimes you can. E.g. one could trivially disallow "jump" control flow, and limit loops to N iterations.

[DarkWiiPlayer → coldtea]

It's more simple than that: pull the plug on the entire turing machine. Lua runs in a VM, so you can stop it from the outside, which wouldn't be possible if the code was running directly in the CPU (Without an OS underneath it, that is).

[mikevin → DarkWiiPlayer]

You could argue this doesn't really count as preventing though. It's preventing a symptom instead of the underlying problem.

[moring → 0x76]

The halting problem only says that you cannot tell if a program ever stops, i.e. takes a finite number of steps but without any a priori bounds. If you limit the number of steps to N, you can just run N steps of the program on your given input and look if it has stopped already.

[tinus_hn → moring]

The problem only says you can’t tell if the programs stops without actually running it. But here you’re running it anyway.

[gwd → tinus_hn]

If you run it and it stops, then it stops. If you run it and it runs forever, then it runs forever. But the point is that you want to know if it's going to run forever before you hit "forever".

[pansa2 → 0x76]

> They could of course just limit the run time

It seems as though this would be more robust than limiting the number of bytecode instructions. I wonder if that’s true and if so, why it’s not more commonly recommended.

[d33 → 0x76]

ePBF prevents infinite loops by restricting the language:

https://lwn.net/Articles/794934/

On: List of All Current TLDs

[0x76]

It appears to be called dotless domains: https://www.icann.org/news/announcement-2013-08-30-en

On: A word for a value between 0 and 1 (inclusive)

[0x76]

Would that include 1 however? If you take the decimal part of something then there is no difference between 0.00 and 1.00 which is I think part of the problem here

On: Ventoy: A new bootable USB solution

[0x76]

This is one of the few multi boot USB programs that worked flawlessly first try. Would definitely recommend.

On: Sqlite 3.30.0

[0x76]

I would definitely use it more if it played nicer having it's DB on a nfs share.

Although I don't know the underlying cause so it may be infeasible.