We're shocked they cost $2 million dollars because until recently they didn't, and it's not because of inflation, it's because private equity has bought up most of the industry, consolidated it, and jacked up prices.
Obsidian the note taking app is a great model to follow as well. The client is completely free and they sell an optional syncing service. The notes are all on markdown files so the client is completely optional.
This is the reason I have always refused to use Bear note taking app irrespective of how good and snappy that app is. Because they keep their notes in a SQLite db now and even though that file can be backed up and handled locally my notes are not easily accessible to me. I can't easily edit my notes in other editors (which I often like to do on my mac), I can't version controlled backup and sync those files the way I want outside of iCloud (which is what Bear uses).
What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues.
> What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues.
They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export it to a temporary text file, allow you to edit it, then update the SQLite database.
> I can't version controlled backup and sync those files
> then they moved to sqlite citing some sync and performance issues
Yes, that's because "plain text" files are bad for performance and harder to sync correctly. For people who (1) have over a hundred thousand notes they want to keep (like me) and (2) want maximum confidence that they're not going to lose years worth of work, that's incredibly important.
The devs made the right choice. You can always write scripts to interface with a SQLite database with an external editor. You can't take plain text files and magically make them as fast and durable as a database.
>and if you really cared you could have made a script to grab a note, export it to a temporary text file, allow you to edit it, then update the SQLite database.
Bear devs advise against doing that: "Generally speaking, it is safe to access the database for reading only"
Thank you for the correction! I was not aware of this.
It's still worth pointing out that this design decision is orthogonal to the decision to use SQLite, though. The Bear devs could have designed it such that you could write to the database directly, or they could have kept the text-file-based design, but still told the user that they can't modify the files directly (as one of my personal projects does). The assignment of blame to SQLite specifically is misguided.
You are right that storing notes as individual text files in the file system doesn't guarantee safe read-write access. But I don't agree that these design decisions are orthogonal.
How would you design a system that uses SQLite as primary storage for notes (rather than just as a search index or metadata store) while still letting people edit those notes in any text editor, sync via any cloud and make them accessible to any AI or other third party software that knows how to use a file system?
Exporting and re-importing every single time you want to edit a note is impractical for tech folks and impossible for regular users.
I can imagine a partial solution using FUSE, FileProvider and whatever the respective file system abstractions are on other platforms. But that would be a huge amount of work.
Also interesting to note that you couldn't actually muster a coherent response to any of my points and just had to make ad hominem attacks and emotional outbursts.
Sqlite is still local first. Couldn’t they just also provide you with notes via obsidian-like file folder structure while using sqlite for in-app performance?
That was exactly my thought. But no I guess they won't. Because they had good old plain text files but they changed to sqlite db and apparently the reason they gave is sync related challenges. Since it's not a FOSS app I don't know the challenges and I feel all other text based notes/editor apps that work on plain text files on disk must be doing something right/different. I don't know.
And as for sqlite being local first - it's not the same. It's the nature of the data a plain text note taking app deals with that neuters that very idea of those plain text notes by storing in a local sqlite db.
I didn’t know they did this change which means it’s time to think about migrating away from bear. Which is a pity because the software itself is rock solid
Yes, I feel the same. A rock solid app dismantled by just one developer choice. Still I won't diss the devs because it's their choice but "a text note" is the last thing I would want "locked" in a sqlite db and bear is a "plain text note taking app" really. So just sad.
I use sqlite3 to load and query random CSVs all the time. It feels a bit weird to hear data described as "locked" within a SQLite DB, because it's one of the simplest non-text formats for me to read data from. It would surprise me of it took more than five minutes to set up a one-way cron job to dump your notes into plain text files.
I don't even use Bear app, I'm just confused by the idea that anything's "locked" inside sqlite when I deliberately put data there for ease of use.
I don't want you to do anything. Use whatever you want! But if you love your tool except for the fact it uses an open database format instead of text files, then lucky you, there's a solution, and it takes all of five minutes.
Not from my experience. I've worked with all three of them. If one can stick with the web UI to provision permissions and the permissions required are simple/straightforward, Google Cloud (again, this is my personal opinion, so please take it with a grain of salt) is the most usable among the three.
BUT all three of them (AWS, Azure and GCP) have pros and cons, so you just have to spend a good amount of time learning their quirks.
AWS IAM isn't well designed, policy attachments all over the place making it near impossible to figure out what set of permissions you might actually have
As hair-splitting, its IAM can be well designed but the management tooling/observability can be lacking.
In my mind, "not well designed" would be "I cannot represent my security need in this policy language" versus the more common opinion "AWS IAM is a black box" means "I cannot understand why I am getting a 403"
GCP's IAM is, in this premise, not well designed because I cannot express ReadOnlyAccess in their policy language without having a constantly updating policy job, because they do not have wildcards in the Action as does AWS. Contrast `Action: ["s3:Get*"]` which would cheerfully include access to a future GetBucketV7 verb to GCP's "storage.buckets.get" which must always be specified, in full, and when storage2.buckets.get comes out, it's my job to find all references and patch them
There is similar issue with AWS. AWS provides a "ReadOnlyAccess" managed policy that has additional privileges that you probably don't want folks to have (e.g. can read S3 bucket content, not just see bucket names/key names). They recognized this and created a more limited "ViewOnlyAccess" that doesn't have access to content.
There's another common fix, which is to apply a permission boundary to IAM roles. This allows the use of generic policies like "ReadOnlyAccess" but can then be further downscoped to resources by tag (or other similar ABAC schemes)
You should not be using any of their managed policies, but creating your own. Using their own managed policies is a strong misunderstanding of how to use IAM.
(I used to work for AWS and am long Amazon stock. In no way do I speak for Amazon)
With Amazon, you are genuinely the customer. AWS may do many things in a bizarre or byzantine way, but it is constantly trying to be there for the developer in ways that many competitors in my opinion are not.
It is, without any question. Even of you work at a Microsoft shop, the benefits you get from vertical integration isn't that clear. Azure requires a far greater cognitive load to handle and to make matters worse ultimately experiences far more outages.
It definitely is built on AD in some form on the backend, just like Exchange Online is built on Exchange, and I believe EXO has its own AD infrastructure for each tenant that you sometimes have to wait for things to replicate to.
In the whole universe of intellectually honest, valuable benchmarks for transportation, do you think ride sharing wins on zero?
I’ll give you an important one as an example: door to door journey times. I support RTO, which is the best way to improve that metric for the average person, which is to say, I was hoping this would be a discussion for out of the box thinking. Or really, what do you invest millions of infrastructure bucks into? All of Uber was only a little more expensive than a single high speed rail line. Why can’t cities run ride share? Why would they run ride share worse than a train service?
Door-to-door time is going to severely suffer on Uber if (and cars in general) are the only option in dense cities. They'll spend most of their time sitting in traffic.
Once you reach a certian density, cars just take up too much space on the road for the number of people they carry, and the only way to meaninfully reduce traffic congestion is to take people out of cars and onto higher-capacity transit.
We already know ride-sharing can't scale up unless your city has super low population density.
I have never wanted my windows search bar to search the Internet (with the one exception being my onedrive). If I want to search the Internet instead of my local file system I'll open a browser
Why would a programing language built around accepting and dealing with millions of connections, and used in base stations, routing, and switching be useful for a mobile device?
Buzz Aldrin would have killed the Apollo 11 crew if Margaret Hamilton had been a worse developer. He pulled up an optional display during the landing that was overloading the computer due to a bug, and the scheduler kept killing optional tasks to keep the control and guidance systems all running.
There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
because it was designed as a general purpose programming language that has robust affordances for weird shit like connections dropping due to a backhoe severing your copper into a PBX.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
The programming model of message passing between processes lends itself well to certain types of apps even if you don't need to handle millions of connections.
For example Elixir/Erlang are currently used in certain IoT applications.
That's taking it to its extreme (unnecessary as your carrier is a different company), but consider building an application like Telegram or WhatsApp, then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
> then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
People say this, but it's not that helpful, IMHO. Front end and backend have different concerns, usually different teams, and using anything other than the preferred language for a client platform tends towards clunky UX.
You can do some sort of core networking library that's shared between clients, and I guess there's reasons you might want that to be Erlang, but integration feels like a lot of work when you can just deal with it in another language. Client side concurrency is so much less than server side concurrency, it'll be fine.
It's not a reason to use a different language, but if you let each team choose an effective language for their work, they may well choose different languages.
That's simply not true. The best language for a front end is the language that's preferred by the platform. Firefox famously rewrote their UI with Java on Firefox because the XUL version was miserable. You don't build iOS apps with Java. You don't build Android apps with Go.
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
Why though? Why would you want your UI code in Python, as an example? Python has nothing in its standard library to help make websites. Tools like PyScript might give you the DOM, but suddenly you'll be using shims for all the other stuff you need, like resize handlers or fetch() or Intl.NumberFormat or anything else you care about.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.
