I actually am in the same position as you - my main text editor is Emacs (well, doom-emacs). After trying out Bear, Standard Notes etc, I couldn't give up editing plain md files that easily. Org-mode is amazing, but the attachments story is just not solved, especially once you throw mobile into the mix.
I've settled on Joplin, as it's the only serious note-taking app that allows for Emacs-friendly workflow by simply using external editor. I just set the external editor command to be 'emacsclient -c'. Now, when I'm editing a note, I just press Cmd-e, and get Emacs for editing - just for that note. Once I finished editing, it's "C-c k", and Emacs closes and I'm back in Joplin.
I actually set Joplin's layout to always show the rendered md, so that it's basically a pretty front-end for my Emacs-powered editing workflow. Beyond that, syncing and attachments are what makes it more or less perfect second brain system for me.
Have you looked at Orgzly, and if so why didn't you go for it? I'm asking because I'm considering switching to Org mode for notes and looking for a good android client.
The main difference seems to be that Orgzly is a native Android app, while Organice is a (self-hosted) web service that happens to render nicely in a mobile browser.
I didn't to run a a whole separate server just so I could edit my org-mode files from a phone, so I like Orgzly better. But YMMV.
Lately I am trying to migrate to just running the native emacs on my phone with Termux :>
You're right that Orgzly is a native app, but you're spot on in that organice just happens to render nicely in a mobile browser. You also don't have to run a 'whole separate server' to use it.
I think writing/updating org-mode notes from mobile just doesn't have the good UX that I'd want. (Not as mobile-friendly as other apps; and not as easy to use or as powerful on a mobile as on a computer because of the limited form-factor).
I don't use mobile frequently for updating notes or scheduling things; so I can live with using some other app (e.g. OneNote/Sticky Notes) for inputting things on my phone,
then refiling that on my computer into org-mode.
I think Orgzly supports a read-heavy usecase like that quite well, since you still get to use org-agenda, have hierarchical notes to view, etc.
Hey Seth, I know there's been _quite_ the effort under the hood to make this product a reality and am curious if you would be open to writing a bit about lessons learned to help others learn about the research & development process.
Sure - in short, we partnered with multiple customers in designing and building this service. Let me check with my team and see what we _can_ talk about :)
If you're interested in a similar solution (albeit closed sourced and managed) that works in a non-cloud, fully off-line (re: internet) environment. Take a look at http://www.hubitat.com. It supports zigbee, zwave and wifi devices and has strong compatibility with the smartthings ecosystem.
Yes, that way we can beat them up for years to come based on whatever mistake they made. It would be even better if they told us which employee made the mistake so we can incessantly mock that employee openly and publicly every time Slack is ever mentioned on HN. When GitHub was purchased by Microsoft, Gitlab came up quite a bit and we got to rehash that whole database outage over again many times over those few days. It was sad.
If it were my company, I would say a little as humanly possible.
It's not about assigning blame, it's about sharing lessons learned with the broader community and being transparent and honest with paying customers about issues that may have significant impact on downstream productivity.
It’s not about assigning blame for the company writing the post-mortem. But it’s definitely about assigning blame for most people reading the post-mortem. Very few people read post-mortems for the sake of learning how to be better at release engineering and ops.
If I pay for your service, and you are transparent about mistakes and flaws, I will be more forgiving about mistakes and flaws in the future, and appreciate the work you do to fix them.
If I pay for your service, and the only communication is, "We know there is a problem, and we'll let you know when it's fixed", I may assume you are not equipped to thoroughly explain the problem, and therefore not well equipped to solve it.
The blame is already assigned. The users already know there is a problem. A post-mortem likely has a positive effect for the readers attitude toward the handling of the issue.
It’s more the people who don’t pay for the service, but might, that are quickest to see post-mortems in a negative light. The only reason they have for reading them is looking for justifications for culling the product/service from the list of contenders for when they ever have to evaluate solutions in that category.
In other words: post-mortems are good PR, but incredibly bad advertising.
And a world-wide outage followed by "we fixed it and trust us it won't happen again" is going to filter any service off of my list more so than "we had a single point of failure running in our CTO's basement and his cleaning lady pulled the plug. Trust us it won't happen again."
I entirely understand what you are saying, believe me I do. But that is not the way some communities take it. We still see messages like "You could move to Gitlab but... you know they dropped their production database a couple of years back? Use them at your own risk!"
We learned a lot from the Gitlab outage. It was a simple mistake and not one they will have again, yet people still beat them up for it. I'm not sure the value is there for the company to be super open about their outages and issues.
Perhaps - but would you even remember it, without the juicy details of what happened? I probably would forget if some service had a few hours downtime a year or two ago, if I didn't know any details to make it stand out from other outages.
Wouldn't they have gotten beaten up over the outage even more had they not offered an explanation?
In my experience, customers are often seeking an explanation/post-mortem because their customers are seeking an explanation. If an upstream service goes down for an extended period of time and all you can do is go back to your customers and say, "Your system was down because our provider's system went down for 4 hours. But they won't tell us why.", that not go over well.
Gitlab's response to the the database mistake was a large contributing factor in my decision to move all of my repositories onto their service.
Anecdotal, sure, but people like me exist. I don't know if we're in the majority. You'd have to measure somehow and do a cost-benefit analysis I guess.
As usual people are taking a comment and twisting it any old way they'd like. Which is fine, that's why we have these communications. To start off, no I am not in aviation. I have run quite a few companies and development departments.
I am not suggesting Slack or anyone else should not communicate at all when they have an outage. A public postmortem, which many people are asking for, is one method. Is it the most effective method? I doubt it. Many people are suggesting that as paying customers they would like to know what happened. Does a public postmortem tell the paying customer what happened in an effective way? Maybe, but maybe not.
When I am running a company I care very much what my paying customers think and are feeling about my service. I will communicate issues directly to them. Do I need to explain to the rest of the world in some great technical detail what happened during an incident? Absolutely not. Do I need to have the first post in Google about my company be an outage postmortem? Of course not. I need my PAYING customers to be pleased with the service I offer and to understand how I will mitigate the damage I have done to them. To me, that's a basic principle of business. I don't have to explain to everyone. I owe everything to my paying customers. Gitlab did a postmortem almost immediately after a major outage and some people tried to slaughter them with the information they shared. It was sad and unfortunate. Their openness was met with some horrible results from the community.
Also, I use Slack. My company uses it for everything including ChatOps for my production environment deployment. We have a hundred of so active users. The outage this morning harmed us. But you know what? I don't pay for Slack. I owe a lot to Slack but they don't owe me anything. I can't blame them for my problems this morning. They are a free service to me. I appreciate that their absolutely free service servers my company so well almost all of the time.
Excellent! If you somehow read my entire message and got out of it that Slack shouldn’t give you detail about the outage this morning, then I somehow did not portray how important it is to emplain issues and resolutions to paying customers. I hope you get a full break down and understand exactly how they will keep you from having this sort of outage again. If they don’t, then it becomes a value issue to decide whether you should move to another system.
My point is only that it does not have to be a large public explanation. You, or the decision maker at your company, who pays a substantial sum of money to slack for their service, should have an explanation until you are satisfied.
It's still alive, to some extent. Priit Kasesalu (of Skyroads, Kazaa and Skype fame) wrote an alternative client back in 2001: Continuum. Some of the bigger servers (EG, TW) are still around. Many of the smaller ones like SFSS have long since perished.
Kubernetes is a little heavyweight for just running a few apps on a consumer laptop. Not to mention the velocity at which it is evolving, and how that impacts APIs (i.e. some minor releases have removed some command line options for kubelet).
Good point regarding the consumer laptop. The point I'd like to make is that using consumer as a proving ground for a future enterprise / cloud play may be compelling.
