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

I’ve been using onesec[1] for a year now it’s been working great for me. Additionally works great on the browser I use.

Onesec uses the shortcut/automation on iOS to intercept app open and not the screen time api you mentioned. So it does take a little time for the initial setup, that’s the only friction I remember from a long time.

Just putting it out there.

I do like the additional social feature here. Would give it a try.

1. https://one-sec.app/


I've also been using one sec, and ended up paying for Pro use. A feature I really like is the ability to increase the duration of the waiting period every time you successfully open the app within a 24 hour period. Just a suggestion if you're looking for them.

It's also very rigorous about switching to the app from other apps, to the point where even if you quickly switch out it will make you wait again when switching back. The ability to bypass this within a 10 minute window (or whatever) is what made me pay for it. Not sure if yours does the same thing, but thought I'd suggest that too. I'll give yours a try. Thanks for making my phone better!


they've executed brilliantly, glad to see it's working well for you. along with the one-tap setup and social accountability features you point out, other noticeable differences between their solution and our are

- we can pull you out of an app at the end of the time you intended to use it for

- we support restricting websites

- we let you accumulate your progress over time via a streak, which is quite motivating (at least for me personally)


One sec lets you restrict websites! But the other two features you listed are compelling. I may give it a try


I just installed it on my iPad, but adding a number (I am on my iPad and I am in the 0.00001% who doesn’t use phones) is a no go. There is an Apple sign in, but I prefer e-mail if possible.

The Apple signup also cuts of at the bottom.

You mention phone use in the description of the app, but also address iPad users if possible.

I am big fan of allowing people to see what would be happen by choosing one over the other, usually with a (?) symbol.

So I am not going to use it right now. Hope you can work with this feedback.


On that I’m aware of is in newer Apple devices with a Secure Enclave.

It is signed by apple and verified as part of the secure boot process.

> The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel.

[1] https://support.apple.com/guide/security/secure-enclave-sec5...


How much did Apple contribute back to the project?


I think that is a relevant question because in related news, Intel didn't acknowledge MINIX.

https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...


It looks like there’s a good bit of industry energy behind this stuff (defense contractors and intelligence agencies don’t want their side’s stuff broken into). So I don’t think this is one of those “Apple takes from the little guy and doesn’t contribute back” stories.


Does it matter? A microkernel isn’t a huge scope, and once it is proven mathematically correct, there’s not a ton left to do; other than maybe adding very niche features or doing touch-ups here and there.


Apple is not using seL4 which is the proven one and which required sizable modifications to the original L4 variant seL4 was descended from. Apple is using a modified version of one of the many other L4 variants.


Apple doesn't use sel4 in the secure enclave, but instead another l4 variant that isn't formally verified.

And they've made a lot of pretty deep changes for example adding native support for Mach-O files.


What is a macho file?


It’s the executable file format for macOS/iOS/*OS, analogous to ELF or PE.

https://en.m.wikipedia.org/wiki/Mach-O


Oh so an .exe


Except that making changes can actually invalidate the proof that were made. At least it matters in the sense that Apple should have made an arrangement so the things added didn't invalidate the correctness.


That's not really how any of this works. The formally verified kernel of the operating system gives you some assurance that your primitives are reliable (unlike on, say, Linux, where you're always a kernel reference tracking bug away from an LPE). But the "application" code you build on top of L4 doesn't "inherit" that formal verification; it's just code, with code bugs. If you formally verify your own code, it's verified, but otherwise you still own your own bugs.

For what it's worth, I'm not sure Apple publishes which variant of L4 it runs on, and there are many of them. The whole formal verification conversation here might be moot.


> I'm not sure Apple publishes which variant of L4 it runs on

The SEPOS kernel is an apparently derived from a fork of L4-embedded they used in Darbat (a fork of XNU to run on top of L4). Not formally verified unless Apple internally has done so.


Absolutely, the problem I'm referring to is if Apple changed the kernel and not only built an application on top of it. I don't know, but maybe Apple just built an application on top, which seems sensible.


The last thing you want to do is to add niche features, those really should be handled in different processes. MM, IPC, interrupts, process creation/destruction/scheduling. That's about it.


That’s what they say about every piece of software. There are always things to fix and add.


True, but as with every other OS project out there, nobody is gonna use it without userland. The kernel itself is already pretty mature, but now the effort should be put into making a full fledged OS out of it.


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

Search: