Fastmail has great calendar (CalDAV), contacts (whatever the open protocol for this is) support in addition to their e-mail. I migrated from Google Calendar & friends several years ago and have had no issues.
Another vote for this option being a viable, and dare I say good, one. In addition to the CalDAV, contacts and email you can use davx5[0] on Android to help with syncing to your (root-not-required) Android device.
This setup has worked well for me for a little under a year at this point.
The problem with this argument is that the set of programs that just fork() and then exec() is fairly small. Sure, shells are small and do this, but then the article argues that shells are a good use of fork().
In larger programs, you're forking because you need to diverge the work that's going to be done and probably where it's going to be done (maybe you want to create a new pid ns, you need a separate mm because you're going to allocate a bunch, whatever). Maybe the argument is that programs should never do this? I don't buy that. Then there's a lot of string-slinging through exec().
That's backwards from my experience, which is that most users of fork() only do "fork; child does small amount of setup, eg closing file descriptors; exec". Shells are one of the few programs that do serious work in the child, because the POSIX shell semantics surface "create a subshell and do..." to the shell user, and then the natural way to implement that when you're evaluating an expression tree is "fork, and let the child process continue evaluating as a long-lived process continuing to execute as the same shell binary". (Depending on what's in that sub-tree of the expression, it might eventually exec, but it equally might not.)
Many years back I worked on an rtos that had no fork(), only a 'spawn new process' primitive (it didn't use an MMU and all processes shared an address space, so fork would have been hard). Most unixy programs were easy to port, because you could just replace the fork-tweak-exec sequence with an appropriate spawn call. The shells (bash, ash I think were the two I looked at) were practically impossible to port -- at any rate, we never found it worth the effort, though I think with a lot of effort and willingness to carry invasive local patches it could have been done.
The vast majority of programs that fork are doing fork() followed almost immediately by exec(), to the extent that on macOS for example a process is only really considered safe for exec() after fork() happens. Pretty much nothing else is considered safe.
Yeah; that would be my assumption too. I worked one time on a significant project that benefit from fork() without exec() and it was a monstrous pain - only if you own every single line of code in your project, have centralized resource management, and have no significant library dependencies should you ever consider doing this.
Yeah, you can't depend on pthreads or pthread mutexes (they're not defined as being fork safe).
The entirety of Foundation (so presumably anything in Swift) is not fork safe either.
To be clear: "not fork safe" in this case means "severely constrained environment": e.g. you can do things liker limits, set up pipes, etc but good luck with much more. I guess morally similar to the restrictions you have in a signal handler, albeit with different restrictions.
Oh no, there's tons of ProcessBuilder type APIs in Java, Python, and... every major language you can think of.
The problems with fork() become very apparent in any Java apps that try to run external programs, especially in apps that have many threads and massive heaps and are very busy.
> In larger programs, you're forking because you need to diverge the work that's going to be done and probably where it's going to be done
That's usually going to be done with clone() instead, no? You'll likely want to fiddle with the various flags for those usages and are unlikely to be happy with what fork() otherwise does.
In my experience, integration with products is not really that hard. I've used sqlite3 bindings in half a dozen languages over the years, and they are generally fairly robust.
Standard advice is to wait two full weeks, then bump your thread (or rebase the patch and send a v2 if there's new conflicts with the maintainer's tree).
Yeah, I'd just use whatever the output of ./scripts/get_maintainer.pl says. It will also suggest any recent committers to that area of the code, which I've found useful in the past. Usually I put the maintainers as To:, and everyone else as Cc:.
If you are okay with gpl software/backend, you could reuse some code of one of my side project: https://apps.kde.org/kalendar/ (support google api, caldav, etesync and Outlook calendars)
Well, at least in the case of Holmes, her legal troubles are not over. I'm not familiar with the details, but among the charges are defrauding investors. The trial just started on Sep 8th.
I use it a lot to figure out why things fail. For example, what if you get an -EPERM from mount()? Was it denied by seccomp, an LSM, because you don't own the user namespace that owns your mount namespace?
strace will tell you it failed, but bpftrace can help understand why.
Note that I said "help": bpftrace can tell you "this function failed with EPERM", but e.g. ovl_fill_super() can fill with EPERM for lots of different reasons. So it's a bit like printf debugging. And you're SOL if the error is generated within that function or from an inlined function :(
