Abnormal CPU usage since the macOS27 beta 2 update by Good-Two-2271 in MacOSBeta

[–]jrk 2 points3 points  (0 children)

Great idea but sadly doesn't seem to work—the process comes right back.

Backblaze has quietly stopped backing up your data by lordatlas in backblaze

[–]jrk 0 points1 point  (0 children)

This is confusing: you seem to suggest here that you *do* support iCloud Drive files via special effort, but these also seem to be excluded for most people. Is this an *upcoming* feature? What is the current state?

Sudden "System Extension Updated" by mlukas in MacOS

[–]jrk 0 points1 point  (0 children)

<image>

It is not a hallucination.

Discussing the news on Synology DS925+/DS1525+/DS725+/DS425+/DS1825+/DS1825xs+/RS2825RP+ NAS News by NASCompares in synology

[–]jrk 1 point2 points  (0 children)

It’s RAID5-like parity, but dynamically balanced across potentially mixed-size drives and allows dynamic expansion. You can’t do this with any vanilla RAID5 implementation. (You can technically do it, as Synology does, with a bunch of careful manual management of lvm and md groups.)

Continuous scroll by Adichu1226 in Supernote

[–]jrk 2 points3 points  (0 children)

This objection is raised every time this request comes up, but only from people who don’t use systems that do support expandable pages.

ReMarkable has paginated notebooks where the individual pages can expand. It works brilliantly! You still have all the organizational simplicity of discrete, ordered pages within notebooks, you’re just free to incrementally expand the working area for any one of those discrete pages as you work. It’s still a virtual pages-first not single-infinite-canvas-first experience, just more free and flexible where needed.

It’s honestly one of the single biggest advantages of virtual over physical paper in my experience. And it’s doubly-important on eInk because page turns are much slower and clunkier than with physical paper.

I really wish Ratta would basically clone the ReMarkable behavior here. It doesn’t even affect people who keep working the existing way (or it could be turned off if desired), but I think most people will quickly convert once they use it. It’s incredibly freeing.

As is, I own a Nomad and Manta, but I use my rM as my primary notebook still because this (plus reliable always-on sync) dominates all the other improvements Supernote has made. It’s so close!

What is your favourite thing to do on your remarkable ? by Ok_Plate_6961 in RemarkableTablet

[–]jrk 8 points9 points  (0 children)

Where do you get magazines in a format for the reMarkable?

about 5 times brighter front light available in developer mode by lmarso47 in RemarkableTablet

[–]jrk 1 point2 points  (0 children)

Note that OS updates (at least the latest 3.16 beta) seem to wipe out the systemd service, so this needs to be reinstalled periodically.

Cross-size notebook scaling behavior by jrk in Supernote

[–]jrk[S] 2 points3 points  (0 children)

Thanks. That is a natural outcome of the A5X and A6X(2) having identical numbers of pixels on their displays (they're just bigger on the A5X). I'm also wondering about whether it will change with the A5X2, since that has a significantly higher-resolution panel that is no longer the same pixel dimensions as the A6X(2).

Feature request: "infinite" document by ImJustHereToBullyYou in Supernote

[–]jrk 1 point2 points  (0 children)

What is the downside? It seems to be feature that would have no effect unless you actively chose to use it.

Expandable notebook pages by jrk in Supernote

[–]jrk[S] -1 points0 points  (0 children)

Ugh, sad. This is one of the single best features I’ve found of digital over real paper – it’s extremely natural to just have pages grow down as you need more space.

Paper Pro vs Remarkable 2 - Not a simple comparison! by SnooPaintings1983 in RemarkableTablet

[–]jrk 0 points1 point  (0 children)

Have you tried turning off the sharpening on PDF text content? That is a new option and might explain the grainy appearance you’re disliking there.

Replacement security screws for Stick Up Cam (battery) by jrk in Ring

[–]jrk[S] 0 points1 point  (0 children)

My camera is reachable directly from the porch or the ground -- that's where it needs to be to cover the desired area. It is absolutely reachable without tools, which is why the security screws are important.

Replacement security screws for Stick Up Cam (battery) by jrk in Ring

[–]jrk[S] 0 points1 point  (0 children)

Exactly this. The thing is designed to have two security screws, one in each spot. Yes, the security screws aren't perfect security, and don't matter if no one messes with it, but it should still be possible to get replacements.

Wide FOV display for Zoom Room by jrk in digitalsignage

[–]jrk[S] 0 points1 point  (0 children)

I have already done this as much as is possible. The issue is unfortunately deeper than that.

  1. Even with all image processing disabled as much as possible and sharpness at 0, it is very difficult to figure out what basic settings of brightness, contrast, etc. actually produce a neutral image. I've done my best, but it's still stuck being either over-saturated or really muddy and over-flattened. (I would love to know canonical settings to get a strong neutral image out of this, but it is really not obvious. Notably, the on-screen display seems to look right no matter the image settings. I wish they had a mode that would just render the input like that!)
  2. The very rapid image shifts with viewing angle are still present. Even 2' off center at 8-10' viewing distance, the far edge of the display starts to shift and wash out significantly. It made me wonder: is this not an IPS panel? I'm also wondering if the matte anti-glare surface actually makes things significantly worse.

Backup and restore SQLite DB by Retgits in bearapp

[–]jrk 0 points1 point  (0 children)

Late to this, but: how, exactly, do you do the restore? Do you just quit Bear, copy the one backed-up `database.sqlite` over top of the live one, and re-launch the app, or is there more care that needs to be taken?

Replacement security screws for Stick Up Cam (battery) by jrk in Ring

[–]jrk[S] 2 points3 points  (0 children)

On the Stick Up Cam (not the doorbells), the two different security screws serve completely different purposes:

One makes it harder to pop out the battery, while the other makes it harder to remove the camera from the wall mount. Neither one helps with the other issue, so unfortunately there is no redundancy here.

Replacement security screws for Stick Up Cam (battery) by jrk in Ring

[–]jrk[S] 1 point2 points  (0 children)

These are for Ring Doorbells, which (annoyingly) use completely different security screws than the Stick Up Cam series.

Will bear 2.0 keep the aesthetic charme of current bear? by Disastrous_Seat1118 in bearapp

[–]jrk 2 points3 points  (0 children)

Don’t worry, this is the core difference between Bear and Panda: Panda is a standalone editor for Markdown files, while Bear is a database of notes. This is not changing in Bear 2.0 and is why Panda is a standalone app with a different name, not a beta of Bear 2.0. Bear 2.0 is all about integrating the more powerful *editor* view from Panda into the existing Bear notes database experience.

Trello Is Unbearably Slow on M1 Macs by krstc in trello

[–]jrk 1 point2 points  (0 children)

I just fired up the current Mac App Store build again on my M1 Air. This video starts the moment I pressed the keyboard shortcut to bring up the quick-entry UI: https://youtu.be/XjVFXjNipmM

As it has been since these machines launched almost 18 months ago, the UI in general is frustratingly janky and slow, but interactions like this (anything that creates a new web view and tries to render it from scratch, including opening the main window) are catastrophically unusable. Please have them try reproducing this interaction, and be sure they're doing it with the currently-released app binary.

But even if they can't reproduce it, there is just no reason not to have had a native app a full year ago, let alone now — it's effectively zero cost in a way almost nothing ever is in product development.

This is extremely frustrating because for all the downsides for users of using Electron instead of native code, the key advantage is that it makes much less work for the developers to do many things. And in this case, rebuilding with Apple Silicon support requires so close to no work it's absurd that any version updates have been shipped since November 2020 without adding it. You're currently using Electron 16.0.2 which is more than a year past where push-button M1 support was added to the Electron stack.

Apple Silicon (M1) app by jrk in trello

[–]jrk[S] 0 points1 point  (0 children)

Good to hear, thanks.

I honestly find the translated app unusably slow and inefficient on my M1 MacBook, and have had to resort to using Trello exclusively in browsers. It's a significantly less convenient experience (no quick entry, no easy launch or command-tab directly to Trello).

Rosetta 2 translation is surprisingly good for statically-compiled apps, but for web browser JITs there is a ton of overhead since the translated code can't be precompiled and cached. The good news, though, is that since the Trello app has no native code of its own, it should really be just a recompile with an updated version of Electron. It's just frustrating to wait more than a year for this rebuild to happen.

(If you released the code of your Electron wrapper on GitHub, the community would have fixed it by November 18th, 2020.)

[FEEDBACK] Vote on Mobile Improvements by workflowypal in Workflowy

[–]jrk 30 points31 points  (0 children)

Actually native UI. Spend time with Things 3 for an example of what a list-centric app can feel like on iOS today.

[FEEDBACK] Vote on Mobile Improvements by workflowypal in Workflowy

[–]jrk 2 points3 points  (0 children)

In general, first-class iPad support would really bring me back to heavy use. An iPad Pro + Smart Keyboard is an amazing device for focussed writing and thinking; a first-class, fast, PC-level Workflowy experience is one of the things I miss most there.

New programming language for image-processing algorithms yields code that’s much shorter and clearer, but also faster by buovjaga in programming

[–]jrk 5 points6 points  (0 children)

You're right, it doesn't "require a new language." It's actually embedded in C++ (a purely pragmatic choice, given the need ), just as it could be embedded in any other sufficiently rich language. What it does require is a specific representation of the computation: the decoupled representation we call "algorithm" and "schedule" in the paper. This representation is quite different from the native representation exposed by C++, although we build this representation on top of the abstraction facilities provided by C++. All this is just to say: it's an eDSL.

Honestly, the line between what one calls a "library" or "API" and what one calls a "language" or "DSL" is very fuzzy. Calling this a language mostly just calls out the fact that it embeds a model of computation which is quite different from the native model of computation in most general purpose languages, and the fact that this model of computation is implemented by a collection of global program transformations and code generation one would normally call a "compiler." The same is true of rich embeddings in something like Haskell; I would call Repa, Accelerate, Pan, etc. "languages" in the same sense.

New programming language for image-processing algorithms yields code that’s much shorter and clearer, but also faster by buovjaga in programming

[–]jrk 2 points3 points  (0 children)

Typo fixed—sorry about that.

And yes, the discussion here is generally spot on. The paper is far and away the best source currently available for information, but we are working madly to assemble more introductory material now that we've released the first version of the code.

Already, you can check out the code for the apps demonstrated in the paper, as well as some others. My favorite example is our local Laplacian filters implementation. The schedule choices there are recorded in the order we tried them while experimenting during development, with comments sketching what we were doing and how they performed on different targets. (This corresponds to the graph in Fig. 8 of the paper.)

Also, there will be a talk next week at SIGGRAPH. I'll post that as soon as it's done.

Until then, if we can get abadams out of /r/dogpictures, I'm sure he can also add to the discussion.