Hacker Newsnew | past | comments | ask | show | jobs | submit | n0ot's commentslogin

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.

https://en.m.wikipedia.org/wiki/Muse_Group


Nice update — hope it rolls out smoothly.


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.


What if you lapse domain renewal for some reason and someone buys it? Some serious accident or life event? I do the same but i use icloud as main one.


you can prepay many domains for up to 10 years.


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.


I don't think you're stripping the userinfo quite right. You're stripping everything after the at-sign, when you want to strip what's before:

  scheme://user:password@some.host:port/path?query_key=query_value&another_key=another_value#fragment


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.

[1]: https://github.com/curl/trurl


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


That's what happens when you use coconut oil


I see you've been around the block a few times


The name...


I'll add Economics in One Lesson by Henry Hazlitt. It provides an introduction to economics from an Austrian point of view, and dispells many common economic fallacies. A big takeaway for me is that the consequences of policies, such as providing loans to certain groups of farmers, have consequences that we cannot forsee.

https://www.amazon.com/Economics-One-Lesson-Shortest-Underst...


I use ProtonMail because I want to use an email address at my own domain. It's actually an inconvenience though, because their IOS app does not let me compose a message with VoiceOver, and when I reached out to them, they basically told me that they're not implementing features until they do their UI redesign. Most of the time, I compose messages in a desktop browser, but the few times I've needed to do so from my phone has required me to open Safari and do it from there, which was a pain.

I'm not looking for military grade encryption in a subterrainian mountain; I just want email at my domain from a service that doesn't read all of my emails and profile me based on their contents. I've looked into hosting my own email from a VPS, but it's not a trivial project, and I'm most worried about being blacklisted before I even start, since it seems most VPS providers are.

Any recommendations?


Might want to try Tutanota or Fastmail. I've heard good things about them but never tried either. I'm currently on protonmail and I am also getting frustrated by their glacial rate of change for reported bugs and quality of life improvements. Also their calendar is one of the worst calendars I have ever used so need to use another service for that anyway.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: