Groxx

The only thing I'm seeing there is that line-wrapping might do [something], and a suggested workaround (which, oddly, they don't implement on the page). And the line-wrapping issue doesn't look like that to me, at least when I do it.

Without the polarizer, you wouldn't be able to see anything. Unless wearing polarizing sunglasses.

But yea, you'd need light on the subject you're looking at it through to take pictures too.

tbh I would probably enjoy a dirt-cheap viewfinder-and-display-less camera, like an even-cheaper charmera. it'd also make a great party-favor thing: hand them out before an event, and optionally gather photos from people at the end.

It's nowhere near thick enough to handle the huge variety of ranges shown in https://www.youtube.com/watch?v=duKNwA96J5Y (thickness clearly visible at ~10s)

The largest source of delay too

Those had a viewfinder that restricted your viewing angles and location to enough of a degree that it mostly didn't matter.

A lot of the time that happened, when I checked it was because a lot of the assets were relatively uncompressed, so DMG-compression shrank them considerably. I haven't noticed the binaries themselves being this compressible.

But that's just "noticed", I definitely haven't paid much attention. And don't have a mac nowadays, so I can't go check my hard drive now.

Kinda interestingly: it zips to 17MB, but the binary looks to be 56MB (davit.app/contents/macos/davit). That seems like a surprising amount of compression for a binary - embedded assets maybe? Possibly this is normal for mac apps though?

Initial attempts and results:

https://cartes.app/#8.61/37.5261/-121.7338 constant up and down movement at any middle zoom level, e.g. this one. zoomed far out or far in (<20km or so visible) it's stable, e.g. https://cartes.app/?allez=San+Francisco+Bay%7Cr9451753%7C-12... moves most of the screen up and down, while https://cartes.app/?allez=San+Francisco+Bay%7Cr9451753%7C-12... is stable. (this appears to be the case roughly anywhere, this is just an example) https://www.dropbox.com/scl/fi/orfhap34liecdon618wkv/Screenc... for a screen recording.

for below, all have "here" selected (not "everywhere") and this same view: https://cartes.app/#12.41/43.0435/-87.89962

"coffee": shows city names in other states, and two places in Iraq.

"valentine": shows... house icons? and a business icon in other states and countries. (top result is apparently a "commune" in France. not sure I'd use a house icon for that tbh)

"valentine coffee": good substring matches for the business name (3 results) and two results in other countries.

"val coffee" (exploring substring behavior): finds one good match from the previous search... but it also shows "Stone Creek Coffee"? what part of that node matches "val" but not "coffee" on its own? https://cartes.app/?allez=Stone+Creek+Coffee%7Cn5066972575%7... -> https://www.openstreetmap.org/node/5066972575

"vendetta": finds 3 good results, e.g. https://cartes.app/?allez=Vendetta+Coffee+Bar%7Cn11268671206... , but why does this work when "valentine" does not?

so... pretty normal results for open-source OSM apps afaict. maybe slightly better than average.

Is this referring to the difficulty of figuring out what "123 w dhuwdaodks plk" means? I can certainly see that (especially internationally - model-based parsing makes a lot of sense there, assuming enough good training data exists), but like I reliably can't even find precise matches in dedicated fields like "business name" or "city". Sometimes it works, sometimes it doesn't, and no open source app I've found yet seems to offer any way to select or filter on fields that definitely exist across locations that definitely exist (I've checked the data by hand). It feels extremely strange, like they're all trying to copy each other without stepping back and figuring out if any of it makes any sense at all to their stated audience.

One of the main things that keeps me from using essentially all OSM-based mapping apps as my primary is that search seems incredibly bad. I can't blend city and name, road and category, can't usually filter by features or open time, and results are almost always something like:

    - a result 500 feet away that sounds nothing like what you searched for
    - a result 23 miles away that shares one word but nothing else
    - a result 572 miles away that has a business name that contains exactly what was searched
    - ... nowhere is there an exact full-name match that is 1.3 miles away, which can easily be found by exploring the map

Are there any apps that do this better? Android and desktop (e.g. linux) ideally. I'd love to use them more, but I've had endless problems using them. Good map data is kinda useless if it can't be retrieved, and trying to work around it by panning around and manually saving a hundred or so favorites really kinda sucks.

Digital sales overwhelmingly use "buy" as the term in their UI, not "rent". Rental is a separate thing, and I don't think roughly anyone is saying rentals should not exist in any form.

There has definitely been a lot of blind-idealism in a lot of P2P systems, yea. Though sometimes that's because it was/is just a PoC to see if it works at all, and then it grows too large to change / needs to be forked.

Iroh is definitely near the top of my "play with it some time" list, that pragmatism is very important for building normal things that normal people will be using :)

Stable IP addresses solve it as well, but these kinds of things are not generally aimed at contexts where those are an option. Even IPv6 isn't generally stable - the prefix is ISP-defined and tends to vary similarly to IPv4 with CGNAT.

There's also "dynamic DNS", which is basically just caching one side of that server/relay/TUN/STUN handshake, and relying on DNS for global discovery.

For Iroh vs Scuttlebutt / DHT, I'll break that into two parts:

1) Iroh uses DHT for host discovery: https://docs.iroh.computer/about/faq#how-is-iroh-different-f... , and Iroh is more about "use that DHT to get a usually-direct connection globally and then you can do whatever you want", while Scuttlebutt is strictly "... and use that connection to exchange append-only logs via gossip, to implement the Scuttlebutt protocol". (Iroh does have some first-party protocols you can use, but it's lower level in general)

2) Scuttlebutt isn't DHT-based, it's "connect to a known IP to get its data and discover connections" -> "connect to them and repeat..." -> "connect further..." -> etc, plus limited-hop feed replication by default. There isn't a global lookup to connect to any member or retrieve any data, it's all friend-of-a-friend connections and you can (and do) lose connection to someone if they get a new IP address and there's no F-o-a-F(-o-a-F(...)) replication route from them that reaches you (rare in practice since they likely re-connected to people they follow, which eventually trickles data through the mesh similarly to before). This is also part of the reason that it works instantly when you're on the same network as someone - it's less "it can work locally if you don't have internet access" and more "local is just a discovery method, the internet isn't special at all because it's all just direct connections".

And as far as I understand Nostr, it's conceptually similar to Scuttlebutt, but with direct support for centralizing for performance (relays) and some degree of mutability / forgetfulness / etc. Scuttlebutt is a bit extreme about its logs being immutable and the only way to exchange data, and it's part of the reason it can have rather major perf issues (like needing to pull gigabytes of data before you can discover a feed's display name). (I say this as a fan of Scuttlebutt in principle, but not in practice - there are lots of practical issues with existing implementations that could be solved, but haven't, and it's a large part of why the ecosystem split into other protocols)

It may also be worth pointing out that DHTs also need stable hosts to serve as initial bootstrappers, and apps that use them tend to hard-code a web URL where they can get a small list of those nodes. They just use them to discover other nodes, and save them for next time so the bootstrappers aren't constantly needed.

Molly has been running just fine as a project for quite a few years at this point. Signal doesn't block them. I think it's fair to say they are fairly strongly opposed to them (for somewhat defensible reasons), but no, they've been fairly nice in allowing other clients.

Applied Science is always worth an upvote

Because that would reverse flipping it over the first time, and our universe's physics are not reversible. Thermodynamics demands the turtle stay flipped.

particularly "and fuzzing", yea. fuzzing generally does intentionally explore boundary values, from what I've seen. for an encoding library like this, I think it's fair to say that fuzzing is a baseline expectation for any decent code, and it almost certainly would've caught this in seconds.

--- edit

concretely, I made a very simple round-trip test with proptest, and got dozens of failures and this in less than a second:

    thread 'signed_round_trip' (50528) panicked at tests/test.rs:72:1:
    Test failed: attempt to multiply with overflow.
    minimal failing input: value = 4611686018427387904
        successes: 2
        local rejects: 0
        global rejects: 0

>One such bug was in the sign function for zigzag decoding of the datrs/varinteger library. On input Std.U64.MAX, the expression (value + 1) overflowed, causing crashes in debug mode and silent corruption in release mode—an edge case that testing and fuzzing would typically miss.

that library is: https://github.com/datrs/varinteger

it seems probably correct, as there's an identical issue filed on that repo a week before this was published: https://github.com/datrs/varinteger/issues/8 (is this a leanstral employee? they have almost no info and only very sparse activity. or did leanstral perhaps just pick up this issue?)

it's a tiny, surprisingly-poorly tested, long-untouched (8y) library: https://github.com/datrs/varinteger/blob/master/tests/test.r... that has about 1k downloads per day: https://crates.io/crates/varinteger [1] which seems rather low.

I don't think I'd consider that such a smashing success that it's worth bringing up as the sole example tbh. though automated detection is certainly useful. or is this a noteworthy accomplishment for this sub-field? I haven't played with proof-writing LLMs, but given the paucity of training data I wouldn't be surprised if they're a bit rough compared to general coding.

1: https://crates.io/crates/varinteger lists it as https://github.com/mafintosh/varinteger-rs which redirects to https://github.com/datrs/varinteger , so despite looking different at a glance it does appear to be the same library

I kinda wonder if it's extracting usable context from 2D proximity between lines? Normal text input wouldn't have that kind of information (though it could, and it's arguably just a lookahead/behind of N characters on average).

Given how many other laptop vendors do this and don't charge extra for it, I think you might be over-estimating it somewhat.

Plus Apple already does this for 20(+?) languages, some of which have difference shapes, which for a macbook means different frame milling. One more letter arrangement isn't much.

I really can't stand the typing-feel of covers. Any of them.

I would MUCH rather buy and use a cheap external keyboard that can be trivially disassembled to clean. Plus then you get to sit back further, and not look down at the screen as much. Win/win as far as I can tell.

Every time I've used CarPlay or Android Auto, I just remember how much better the experience was with a tablet velcro'd over the main display. Immediately obviously better in every single way, and dramatically cheaper and easier to replace if desired.

I get the goal, and I'm glad there's at least some semblance of a standard. But it's still bad.

The immediately obvious and simple to handle on-disk format for everything I cared about was one of the things that convinced me to give it a try. Well-crafted exporters are great and all, but I really like being confident that I can convert it by hand even if the company ceases to exist.

Backups are easy too: you can very reasonably just rsync the library folder, and it'll be recoverable from that alone (I tried it! Worked great). You'll lose accounts and image-content search and iirc faces (possibly painful), but most of that is trivially rebuilt or not very interesting for single-person scenarios.

yea, I don't think Opus Magnum is my favorite either. I just think it's a good starter, to get a gentler introduction to the many-step puzzles and those optimized-build leaderboards - if those leaderboards call to you and you like fighting your way towards the left, you're going to be a Zachtronics addict in no time.

if you don't enjoy them, then you've at least had a sizable taste of the mechanics and know why it's not your thing, rather than getting hard-blocked early on because you couldn't figure out a trick :)

"modify the windows installer via a binary patch to work around the continued bloat and feature crippling" really isn't "local accounts are supported" in my book. that's like saying "the 1965 ford mustang was an electric car" because someone did a conversion on it a few years ago.

and the actually supported workarounds have disappeared, last I saw - bypassnro and disabling internet both failed completely for me, the last time I tried. maybe they have come back (it has intermittently failed in the past and come back), but they're very clearly doing more to remove it than they did a year+ ago when bypassnro worked easily and consistently.

for anyone on the fence about these games: I'll highly recommend Opus Magnum as the starting point. It's a good intro-to-Zachtronics game because every problem can be brute forced if desired - in many of the others, you need to make some clever arrangements and logical leaps to progress, due to very limited playing field sizes.

they are quite unique and very well-made though. if you like sequence-puzzle games but are getting tired of the endless flood of Sokoban-flavored things, give it a try!

Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?

Yah, it seems blatantly hostile how much they hide it.

I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.

But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.

I've been wondering why hibernate didn't work with encryption, because this seems like the extremely obvious way to handle it, but I have struggled to find anything about it for years - glad to hear it does exist!

But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.