"JavaScript: The Good Parts" was a great and a very important book back in the day. I am sure it inspired many of the improvements JavaScript has seen since then. But as it has seen these improvements, and as they were many indeed, I am not sure the book is still as relevant as it once was. Or to put it differently: There are many more good parts to JS these days compared to when the book was released :)
FWIW, there is a tiny webapp on the device that you access when you follow the instructions above. You do not need to install anything and it worked perfectly fine for me so far.
Also, you can ssh into the device and even get root access. I have not tried it yet but I guess scp would work as well.
These features were free to begin with! Then they got greedy (imo a marketing / sales background product manager thought they should price more aggressively) and started charging for basic features! Honestly the device was completely unusable at that point. And now they are reverting ONLY because Kindle Scribe is going to be out soon, and they need to look like they are a similar product. I can guarantee that unless they have a major shake up in their organization or put it in writing that they will not change their service offerings, this will absolutely happen again.
Their services are all hosted in Hong Kong, which means that they're subject to China's domestic spying apparatus and rules on encryption.
You'd have to be a moron to trust a device which uses Chinese-territory-hosted servers to store and OCR your documents.
The remarkable2 is a more expensive (if you count subscription fees for 2-3 years), far less capable, far less private device than an iPad with Apple Pencil. You can get the screen texture for a few dollars off Amazon.
Almost any iPad can do text recognition and handwriting recognition completely offline; this thing can't do any of that without an internet connection.
They keep having to pimp it on HN because it's not a competitive-in-the-marketplace device.
The use case for the ReMarkable is not the same as the use case for an iPad. There are other e-ink writing tablets out there besides ReMarkable obviously, but iPad did not at all satisfy what I was looking for in a note taking/paper reading tablet. It was like a glorified second phone with a shit writing interface. Very glad I switched to e-ink.
All cloud features remained free for people who owned the device before they implemented the subscription model as far as I know, it's not a bait and switch.
This is true for now. As someone who bought the original ~3-4 years ago, I feel very nervous that the way I use my $500 device is not aligned with the company’s long term road map. Add the fact that I recommended this device to a bunch of friends and family (the v1 is a great product) and I am personally on the hook for figuring out how to get half a dozen annoyed friends/family to get ssh access. The cost of them changing this is high for me personally and I really don’t have a lot of faith that they will not discontinue this subscription waiver at some point in the future.
This is the true difficulty with clawing back features in order to charge for them: you break trust.
Businesses income in aggregate is not immediately affected by choices that break trust (in fact, the short-term balance sheet might even show increased profits) but it’s very hard to un-sour people once you’ve broken trust.
But if you're worried about greed ruining a good product, Kindle Scribe is an Amazon product and Amazon isn't exactly known for being a champion of its customers (though maybe I'm unfairly conflating their web store with the tablet branch).
> or put it in writing that they will not change their service offerings
Also I put zero faith in what a company puts in writing unless it's in a legally binding contract. Anything else is trivial to change or ignore.
> (though maybe I'm unfairly conflating their web store with the tablet branch).
this is exactly what you are doing. I've owned every kindle model since it was first released.
I no longer shop on amazon's marketplace and cancelled my prime membership. If i want to buy "made in china" products i can cut out the middleman and go to aliexpress.
Only time will tell. I'd be tempted to buy one, but at present I'd rather wait some more time for the PineNote to reach an usable state. My use case would be mostly at home, so it would be essential to be able to read from local NFS or SMB shares, caching on the on board SD card the latest accessed books, something that would be trivial to implement in a Open Source reader, but I doubt commercial ones would do. And of course any attempt to force me use a phone app or any online services would immediately turn me away.
The thing is basically a tiny Linux machine running a webserver and ssh. You can mess with it all you like (with the usual caveats about knowing what you're doing and risking bricking it).
I've ssh'd into mine and it looks just like you'd expect. I didn't mess with anything (because I know that I don't know what I'm doing with it).
I've also used the "email me a PDF of this page" function a couple of times and it works perfectly.
I bought mine before the subscription kicked in, and got grandfathered in, so I can't comment on that.
scp doesn't work as their default reader renames the file and keeps a database. (That's probably why it doesn't present a usb disk.) Getting files to my remarkable (1) is honestly my only complaint with it.
You can run koreader or others, and then scp would be usable.
FrOSCon (free and open source software conference) decided to go fully online this year. A lot of talks are in german, but many are in english. See the schedule here: https://programm.froscon.de/2020/
It is so nice to see this on here. I started frab way back for FrOSCon, a german free and open source software conference (which you should totally attend if you can make it!).
I stopped contributing when I stopped organizing FrOSCon, but thankfully Mario, the current maintainer, has picked it up and he does a tremendous job ever since. Also a big thank you to all contributors.
Also, the 5.1 series will not receive any future security fixes now that 6.0 is out.
So you could consider upgrading to 5.2 instead of 6.0. This is just one minor version step so should be less daunting. And 5.2 will receive security updates for a while yet.
Craig from Citus here. There are a number of issues with one schema per tenant, the biggest one is that at a larger scale Postgres will mostly just not work anymore. Things like pg_dump start to fall over and while this has been improved some, there is still an upper limit somewhere between 1,000 and 10,000 tenants. Further having to then run schema migrations against all of them can be quite painful. There are tools that help on the schema migration front, but what we've seen is that again at scale things start to break. If you'll only ever have 100 customers then by schema can work for you.
Performance, management, SLA are some big issues with any "SQL as a service" project. How can you garuntee 1) disk utilization per tenant 2) CPU utilization per tenant and 3) transaction volume per tenant? Most simply, I don't believe you can, and we concluded it's simply not worth going down this path of shared, multi-tenant database (postgresql not withstanding, any RDBMs would have the same issues).
Our conclusion was that the only way to get the required level of management per tenant, and to support truly massive number of tenants, was to use an inprocess database over https ie SQLite and Apache. But, SQLite has an image problem, it's everywhere, and nowhere. It's built with some fundamentally different decisions than other databases, and isn't traditionally used for web applications.
So that's the course we took, links in my profile for more info.
> use an inprocess database over https ie SQLite and Apache
Why not, but you introduced a whole bunch of new issues. SQLite only supports a single writer at a time. This is a problem if you have a lot of users on the same tenant. This is also a problem when you need to create an index, for example, which is not a background operation.
Indeed there are trade offs, and high write applications are a weak spot of this approach. But for low to medium write applications (ie most applications?), SQLite WAL [1] option performs really well. We implement application level caching via a X-Query-Cache header[2], in that case, you're serving directly from redis. This set up can scale really, really well.
One issue we had: pgdump performance was abysmal for dumping a single schema out of thousands.
We had to write a custom backup script to handle individual backups, taking advantage of the knowledge of our own database architecture (basically: we don't have to read the schema list and figure out relationships between them because we already know that).
If you read pgdump's source code, when doing the actual backup it uses postgres COPY command, so it was easy enough to write our custom exporter.
Also interested in this. I architected my system with a single multi-tenant db. My thinking was that it simplified things initially (less admin / backups / pooling etc) but it would be far easier to split into individual dbs later (than to combine).
We are a b2b product and we've picked up customers around the world. Now it seems like it might make sense to shard geographically. Is that common?
We shard geographically, with a single multi-tenant Postgres schema per geographical area.
You run into corner cases when a customer wants to operate into two distinct geographical areas, so basically you may have to maintain a central repository of tenants and, ultimately, under the hood, your tenant primary keys are not handled via local sequences.
I also have a database with schema per tenant. In the tenant code I set the schema. I like it and would like to see more information as well.
One issue, I think, is that it does not have full isolation and no easy sharding.
As sad by another commenter, I plan to distribute my schemas on multiple servers when neccessary, like the sharding approach.
My personal, recent experience is that my current startup's business model would be poorly served as a result.
You see I originally thought I was building a SaaS service, but it's actually turned out that my customers needed a two-sided network. A per-tenant schema would've been an painful impediment to making that paradigm shift.
Both, the original and asciidoctor, offer a CLI tool to convert asciidoc to different formats (and there is always pandoc). Additionally, asciidoctor aims to integrate with JVM languages courtesy of JRuby. So you have multiple implementations callable (in one way or another) from any language imaginable.
I agree, even on smarthires.io, where positions are supposedly vetted and only open to YC alumni, I've had several companies that have abruptly ended the conversation when I state I'm based in Europe, despite my profile clearly stating that my preferred location is London or Remote.
