I tried using pass once. I like that it follows the Unix philosophy, and I want to like it, but the fact that all of your account names are visible in the clear is a deal breaker for me.
I honestly don't know how anyone thinks terminal support in VoiceOver is acceptable--it's virtually unusable. It's so bad that I used to fire up a Windows VM just for a functioning terminal, and while I was at it, I'd browse the web and use Notepad++ there, because Windows accessibility is just better (I used NVDA). But then I discovered Fenrir, figured out that it worked with Vim (NVDA doesn't), shut down the VM, and never looked back. Today, I use Wezterm, which VoiceOver doesn't read at all. In my case, that's good, because the only thing I want talking in the terminal is my terminal screen reader (I started writing my own, and it's my daily driver).
To be fair, reading the terminal is a completely different beast from reading a GUI. In addition to building a static view of the screen for review, you have to handle dynamic updates (auto read). Cursor movement tracking, figuring out when to read what, when not to read (an f just appeared on my screen, but I just typed the letter f; if key echo is turned off, I don't want to hear "f"). If a line was just added, it should be read, but if my cursor was moved to a different line, I want to hear the line it moved to, but not if that line was just read because it just appeared. All sorts of rules you sort of discover as you go. But the one thing you definitely don't want is for any new change to interrupt what was already being read, and that's exactly what VoiceOver does.
Using VoiceOver compounds the not responding issue. I don't know how its internals work, but I imagine it tries to keep a view of the window's state--tree of elements, ETC. If the window has a lot going on, VoiceOver can get really sluggish, and I think it must somehow block the underlying app's ability to send/receive events, because you will press VO+right arrow to move to the next element, VO says "Safari/Chrome/Brave" not responding, and if you open up Force Quit, it reflects the same there. Reading a large diff on GitHub flat out doesn't work for me at all. Also, sometimes when navigating certain webpages, VoiceOver will just outright crash. Luckily, it does restart itself (not that pressing CMD+F5 is hard), but then my focus is moved to a completely different part of the page.
This seems really cool. I use Secretive and would like to switch to this native solution. The one thing holding me back is that I like that Secretive allows you to create keys that don't require TouchID, yet still notifies you when they are used.
I use an external keyboard, so reaching for the fingerprint reader isn't as easy as it would be if I just used the internal keyboard. Fine, ControlMaster is a good compromise. Except when git signing (every commit) is a requirement, you have to touch the reader every, single, time. That's fine when making routine commits, not so when rebasing. Ideally, I could tell the SecureEnclave to notify me, but don't require biometrics for the next 30 seconds or so, but since that's not a thing, that I'm aware of, I'd at least like to know when my git signing key is being used.
I know accessibility for low vision users was mentioned, but I wonder, with all these changes, whether version 4 will be accessible to screen reader users, and if so, whether any major features will nevertheless remain inaccessible.
We're using the framework my team on MuseScore Studio created for the UI in Audacity. This allows us to port over the significant amount of screen reader support we built over there too.
We'll need to spend time making sure it's applying correctly to every corner of the app - but when it's done, the app will be far more broadly supported than V3.
I would guess accessibility will be similar to the current version of MuseScore since the same company (Muse Group) is leading both open source projects. So maybe look at MuseScore.
I use a custom domain with iCloud+. That works for me because I'm very much in the Apple ecosystem, but I can easily move somewhere else whenever it's no longer the best option for me, and I did just that when I moved from Proton to iCloud. I've set this up for my wife as well. It can be as simple or as hard as you want it to be, but above all, I'd strongly encourage you to use a domain you own. Email has become our de facto identity, and we should be in control of it.
+1 to this. I was using Fastmail and it was very good, but since I'm already paying for Apple One, I decided to switch my e-mail (in my own domain) to iCloud+ to.
The only con I see is: there is no way to add separate 'mailboxes' to it. I can register multiple addresses, but it's still one account, thus one mailbox.
I was working on a CAA implementation and wanted to use one of my domains (at Namecheap) to test. This was around 5 years ago. I had the same frustrating experience with support. I understand front line support personelle might not know what the heck an RFC is, but you'd think this would be a case when escalating to the next level would be warranted. I felt like they weren't even reading half of my message. I switched to different nameservers, and that worked fine in my case. I did eventually move over to Porkbun, but not for that reason.
I'm also in the southwest suburbs, and have Comcast. My internet went out for about ten minutes at around 9:20 CST. I disabled WIFI on my iPhone only to discover I was still offline, and had no signal. Not sure whether the Comcast outage was related, but it came back up very quickly, whereas I still have no cell service (AT&T). My wife does have service, even though we both have iPhone 15 Pros.
> If you never initialize a heap allocator, you can be confident your program will not heap allocate.
This is true for the standard library, where I can trust that no hidden allocations will be made. If I pull in a third party package, nothing guarantees that that lib won't init a new `std.heap.GeneralPurposeAllocator(...)`, right?
No, and it would be impossible to prevent as well: obviously library code can do anything it wants, including asking the kernel for memory.
But this is one of those things which just wouldn't happen in practice: custom allocators are so embedded in the Zig philosophy that I cannot imagine competent Zig programmers writing a library that did something like this. It's just not what you do in Zig.
It's not impossible to prevent. Some languages do just that using capabilities. You can get capabilities by declaring them in your main function, for example, and only passing the capabilities you want to code downstream, such that it becomes literally impossible for any code to get IO access or allocate memory, for example, if the code is not explicitly given that capability. I believe Pony and Unison are examples of languages that do that (not for allocation, admittedly as they are both GC'd, but the concept would work in a language like Zig).
The thing you're talking about is just not possible in a low-level, runtime-less language like Zig. Like, utimately Zig. libraries need to generate arbitrary assembly to run on your architecture (like if you want to write a driver or something), so you can't stop someone from just writing a thing that does the syscalls itself.
The kind of "capabilities" style languages you are talking about almost always have either a runtime that handles the actual syscalls, or they don't have the capability to compile directly to the assembly you need, everything has to pass through some library. Zig does not fit into either category: it has no runtime, and the whole point of the language is to be a low-level C replacement.
Right, but that would be unidiomatic and the third party package should be criticized for doing that. Proper form would be for the allocator to be chosen by the user of the package, supplied as a parameter.
Seems like an excellent use case for trurl [1], a tool built on curls url parsing functions (which can presumably handle any weird url format you throw at it), though I'm not sure how well packaged/available it is.
Doesn't chrome remove the user info (or at least the password part) from the URL?
(On mobile now cannot check)
EDIT: check: it does it only after successful access. If the browser still presents the basic auth window because the backend responds unauthorized then copy&paste data will contain the full userinfo
reply