milkey_mouse

I think that's the author's point. They aren't endorsing the "human eye can't see the difference" thing, it's just become a myth gamers love to debunk. I've heard more people mention it mockingly/sarcastically than I've ever seen claim there is no difference between 30 and 60 fps unironically.

> I am thus convinced that philosophers ENJOY the mud, not the clarity.

I agree that this describes many philosophers, but "quietists" such as John McDowell and (late) Wittgenstein would disagree:

https://en.wikipedia.org/wiki/Quietism_(philosophy)

This would be a pretty interesting exercise. I can imagine using path length/distance across the word2vec space or even just the inverse of an ngram's probability. E.g. "zombie" and "fungus" may be close together, so would "cicadas" and "horror" maybe, but "cicadas" and "sex" probably don't appear together very often.

> Just allow users to tag an answer as outdated

StackOverflow is testing such a feature right now: https://meta.stackoverflow.com/questions/407613/outdated-acc...

I don't know if this service allows uploading images, but if it doesn't, storing text is cheap. "Too cheap to meter," as they used to say about nuclear power (although that turned out to be a pipe dream). For simple sites like these GitHub & GitLab Pages is free, or NearlyFreeSpeech is "nearly free" as the name implies. Hell, set up an sdf.org account and serve out of public_html. One of my hopes for the future of computing is as storage, bandwidth and compute get more efficient and cheaper (and fees on financial transactions don't, and adblockers become more prevalent), people decide it's not worth the effort to charge users fractions of a penny for their use of a service. Having the site's admins cover the cost isn't a big deal if it's on the order of $5/month.

I would be more concerned about moderation than storage or bandwidth usage. It's more difficult for text to be illegal than images, but it's clearly still possible: hate speech, copyright violations, etc. (whether it should be is another argument...)

> I generally agree with the idea of a VM that is simple to implement, but... shouldn't look like real hardware

You might appreciate appreciate Urbit's Nock, a "functional assembly language" based on combinator calculus which can be specified in ~40 lines of text, and implemented in ~100 lines of code:

https://urbit.org/docs/nock/definition/

As one might imagine, a naïve implementation of this spec would be extremely slow (for example, decrementing n requires incrementing another variable m in a loop until m+1==n, which is O(n)). A regular JIT can make even the braindead implementation decently fast, but in practice, specific implementations are recognized by the interpreter and replaced with faster ones. The benefit of this approach is that the code itself is rigorously specified by the combinator definition, and you can point the finger at the interpreter if the output from the optimized version differs from the naïve implementation.

I totally agree. There is more than enough "unmapped" area on the motor & sensory homuncului[1] (creepy image warning) to be repurposed as an I/O channel by retraining the brain. In general, brains are plastic enough to remap senses like this[2] given a handful of months' work/practice. Adults are capable of learning ASL, for example, which uses completely different "output channels" from spoken language. Even when learning to drive, the car can start to feel like an extension of one's self (and I'm not a car person at all). Famously, people who become blind begin to develop better acuity in their other senses because of all the "freed up space" in the visual cortex (which I'm sure is an oversimplification, I'm not a neuroscientist).

We have so much raw data coming into our brains--via sight and sound especially, but surprising amounts via other senses as well--that I see little reason to add "additional senses" or outputs when we have rather high bandwidth already. Heck, my thoughts run ahead of my speech or typing fairly often, and both of those are pretty low-bandwidth channels.

One-hand chorded keyboards[3] are perennially reinvented by someone with an Arduino and a few buttons (not to belittle that work!) but you can't just pick up a chorded keyboard and type as fast as a regular one, so they are generally treated as a novelty. But if one spent as much time learning to use a chorded keyboard as they did a regular one, I'd bet they'd be just as fast. Perhaps the reason fluent computer users show little desire for better human-computer interfaces is that they are afflicted by a generalized form of baby duck syndrome[4]. To mix metaphors in a really confusing way, interacting with a computer with a keyboard, mouse, and monitor feels like using GNU nano: shallow learning curve, but it tapers off quickly. I wish I knew the Vim of HCI: I'd be willing to practice for years to adapt to it, to compute more efficiently for the rest of my life.

[1]: https://en.wikipedia.org/wiki/Cortical_homunculus [2]: https://en.wikipedia.org/wiki/Cortical_remapping#Plasticity [3]: https://www.stavros.io/posts/keyyyyyyyys/ [4]: https://en.wikipedia.org/wiki/Imprinting_(psychology)#Baby_d...

Sometimes "the industry" "moves on without" a valuable perspective. That doesn't mean those "left behind" (e.g. Richard Stallman) should give up. Something something "marketplace of ideas."

But yeah, GP, get a Let's Encrypt certificate for the sake of your readers!

> why would you think this?

I don't know, I probably think a lot of things that are wrong. Up until your last post I assumed the waveforms were provided by E Ink themselves. When you mentioned different panels needing different waveforms I assumed you must have meant per unit, not per model of display, because the latter is obvious. If they were unique per individual display that calibration would need to be done in the factory. Did I misunderstand, and you meant per model of display, and not per unit?

Come to think of this, I can verify this right now. Here are the results of `sha256sum /var/lib/uboot/waveform.bin` on two different Remarkable devices of the same model/SKU:

185515bebf37d3e9d99ffa1f13a2804bbb2b64464fa6fc5067475fb6f65ff6b0 /var/lib/uboot/waveform.bin 185515bebf37d3e9d99ffa1f13a2804bbb2b64464fa6fc5067475fb6f65ff6b0 /var/lib/uboot/waveform.bin

You'll have to take my word I didn't copy the same line twice... but as you can see, they're the same. So I don't necessarily think the waveforms are different per unit or batch.

> You say that as if it is unique to E Ink. Whereas its standard across the entire display industry.

Sure. But I was talking about why I bought a Remarkable instead of building an open source e-ink laptop--certainly not a product with volumes high enough to get any manufacturer to pay attention. Obviously I would have the same problem if I were trying to build a regular laptop with an LCD screen (or modern CPU, or WiFi...). For hobbyist projects you're certainly not getting any support from manufacturers. The best one can hope for is open datasheets/manuals and even that is pretty rare...

I suppose instead of "difficult stuff" what I should have said is "they signed E Ink's NDA and thus have access to whatever tool they use to generate waveforms, panel-specific or no." I don't mean to heap credit on Remarkable, it's just they're a Real Company™ who E Ink will talk to, and I am not. Frankly I consider getting a waveform that doesn't look bad or cause burn-in over time a more difficult achievement than an open source driver or a hardware e-ink driver (indeed, lots of SoCs have them). Hence '"secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.'

> The driver is open source.

Clearly, or I couldn't be running Linux-libre with it.

I have thought about building an E-ink laptop for a long time but eventually I bit the bullet and bought a reMarkable[1]. They've figured out all the difficult stuff about e-ink (did you know that to flip pixels, e-ink displays require annoyingly proprietary lookup tables of waveforms that can be up to 5-dimensional?) and worked with E-ink directly to implement said waveform table, very low-latency partial updates, and other e-ink "secrets" that could very well be worked out via reverse engineering but are otherwise under NDA. The device is also very thin, if you care about that sort of thing. The main downside is the hardware is closed source (and rather expensive, but any e-ink product not made of recycled Kindles will be).

The device comes with SSH enabled by default, with a randomly-generated password in the settings menu. Its main UI is a proprietary app, but there is a vibrant community of open-source "hacks"[2] ranging from binary patches adding features to the stock UI to a fully libre replacement OS based on Parabola[3]. Its USB port works in host mode, so you can plug in a keyboard and use it as a terminal. I've been meaning to make a nice cover for it with a built-in keyboard like the MS Surface devices.

[1]: https://remarkable.com/ [2]: https://github.com/reHackable/awesome-reMarkable [3]: http://www.davisr.me/projects/parabola-rm/

There is a JS sigil generator: https://github.com/urbit/sigil-js#basic-usage And a Figma plugin: https://github.com/urbit/sigil-figma-plugin

Urbit names are just another representation of a 32-bit number, like the sigils. You can use any 32-bit number as the "seed" for a sigil.

Urbit also developed a solution for turning a number into an avatar, although theirs only have 32 bits of entropy, and to be honest there are many that are difficult to tell apart:

https://urbit.org/blog/creating-sigils/

Why would foveated rendering require raytracing? Most existing foveated rendering tech uses a traditional rasterizer and renders the periphery at a lower resolution.

And VGPUS are isolated from one another, that's the whole point-so using multiple in one application would be very difficult, as I don't think they can share data/memory in any way.

Ah, that Segoe UI WPF app takes me back. I made so many little utility apps like that when I first got Visual Studio. WPF/WinForms is what I made my first GUI apps with, and first discovered why one shouldn't do blocking computations on the main thread...

> My understanding is that CPU/GPU per application can make only single draw call in sequential manner.

The limitation you're probably thinking of is in the OpenGL drivers/API, not in the GPU driver itself. OpenGL has global (per-application) state that needs to be tracked, so outside of a few special cases like texture uploading you have to only issue OpenGL calls from one thread. If applications use the lower-level Vulkan API, they can use a separate "command queue" for each thread. Both of those are graphics APIs, I'm less familiar with the compute-focused ones but I'm sure they can also process calls from multiple threads.

"OIL LENS: hufhuf oil held in static tension by an enclosing force field within a viewing tube as part of a magnifying or other light manipulation system. Because each lens element can be adjusted indivually one micron at a time, the oil lens is considered the ultimate in accuracy for manipulating visible light."

-Dune, Frank Herbert, 1965

I have purchased libre software. An example is RCU (reMarkable Connection Utility): http://www.davisr.me/projects/rcu/

If my grandmother had wheels, she'd be a bicycle.

It is a ublock list, or at least ublock compatible. You can import e.g. https://raw.githubusercontent.com/jmdugan/blocklists/master/... as a custom ublock list and it will work fine. I've had these lists enabled in uBlock for years.

Not all tiny fans are loud. I built a very quiet Raspberry Pi IP camera[1] actively cooled by a little Noctua fan[2], and it's so quiet I can't hear it when I put my ear up next to it (as you'd expect from a fan that costs almost $1 per cubic centimeter).

[1]: https://github.com/milkey-mouse/basket/tree/master/hw/case [2]: https://www.amazon.com/dp/B00NEMGCIA

You're correct, but I recall a Tor dev saying at one point that HTTPS for .onion wasn't completely useless, I think in that more secure settings (CSP, etc.) apply to pages loaded with HTTPS.

Correct, Starlink does not currently support IPv6.

Whoa, you disassembled it between moves and it survived? I've never been able to do that without the particleboard getting too messed up to accept the screws.

Something about renting furniture doesn't sit right with me (pun intended). I'd much prefer to be able to sell it back for a fraction of the original cost than to have to pay a monthly fee for my table.

I can't say this is never a problem-can't prove a negative-but my house is full of IKEA furniture, half of it bought used, most of it made of particle board like you say (although they do have nicer real wood products), all of which having survived several decades of use.

A leg came off my desk once. I drilled new holes and was able to screw the leg back in. Similarly a slide on a dresser drawer somehow got bent out of shape and I was able to get a single replacement part sent to me from IKEA. The only real problem I have with IKEA furniture is that most of it can't survive disassembly and reassembly well enough for me to flat-pack it when moving; I have to move it fully assembled.

I am amazed that such cheap (in both price and quality) furniture can last that long. Granted, I haven't ever tried to karate chop my desk in half, but I have come to the conclusion that even the worst furniture is fine. But I probably won't give my $20 desk to my eventual grandkids.

Urbit's IDs are 32-bit numbers represented in a pronounceable format (search for `@p`): https://urbit.org/docs/tutorials/hoon/hoon-school/atoms-aura...

Meanwhile in the real world, there's proquints: https://arxiv.org/html/0901.4016

You're essentially describing AMD's SEV[1] as mentioned in the article. It piggybacks on the memory encryption implemented in the Zen architecture by giving a separate key for each VM. Ostensibly, the host can't interfere or snoop in the VMs, assuming you trust AMD. I'm surprised it hasn't been more widely adopted.

> protected from anyone except very few who could extract private key from secure chip

The way I understand chip manufacturing it would be hard to diffuse a separate key into each chip. This means it'd only take one of those very few people to extract and leak the key (or cut out the middleman and leak it from inside AMD) to break it for everyone.

> The only real world issue would be side channel attacks.

This is probably a much bigger problem in practice. Spectre & related attacks have been effective against Intel SGX[2], another "trusted environment" inside a larger system.

[1]: https://developer.amd.com/sev/ [2]: https://arstechnica.com/gadgets/2018/08/intels-sgx-blown-wid...