291–300 of 336 posts
Earlier quoted context omitted.
As someone who was there to witness it when it happened, that is not the impression I got at all, and I think Dang may have taken the more humble interpretation in that remark.
You don't need to have been there, though, as anyone can read the perfectly-preserved exchange even now.
Earlier quoted context omitted.
Why can't a company use cloud? It's not like there's Amazonbox client I could install now and get the same service. Dropbox never was about the storage itself, IMHO - it was about the ease of usage. There were enough options to get storage - cloud or non-cloud - when it came out, but none of them had the easy folder-based sync and sharing (public folder) of Dropbox.
It's not if the company uses cloud or not. It's if they are solving the hard problems or instead, outsourcing the technical challenges to their cloud provider while charging the user a non justifiable premium for the intuitive user interface :-) So it's about the eventual value add and the business case. The challenging part is to provide the back-end. Get massive storage, with proper checksum integrity, at a cost ef…
Earlier quoted context omitted.
You don't know what this database is --- upthread, you said you don't even know what the product is. All you appear to know is that they should be using something like RDS. Isn't that a weird position to take?
it's also kinda weird to write a blog post about a database being used for what is apparently a very specific use case without mentioning what that use case is. the burden of proof is on tailscale to explain why they need to deviate from industry norm here and clearly from the entire comment thread of people wondering the same thing as me they haven't done that. this blog post might actually be valuable if they inclu…
One thing that would have helped your writing on this thread: a lot more question marks. It's OK not to understand something! Asking questions helps everybody.
Earlier quoted context omitted.
For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database sc…
There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.
Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it.
This was Laravel 5 days and I'm sure much has changed.
I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
Earlier quoted context omitted.
Sounds like you need to do a lot more research before commenting on this? It's pretty easy to find in the Litestream docs that it replicates to S3, Google Cloud Storage, Azure, and other options even including SFTP. In fact by off-loading the storage integration details to Litestream, the Tailscale people now get seamless storage vendor independence almost for free. This is what a really smart and future-proof soluti…
or they could have used mysql or postgres hosted by aws, gcp, azure, etc? i would put money on this not being the last time they change databases
Earlier quoted context omitted.
For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database sc…
There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.
And if I'm gonna deploy a new framework greenfield, I'll just go with Django since Python has more mindshare in my industry.
Earlier quoted context omitted.
Not quite, I got bitten by weak type system more than once.
Funny in here, people praise SQLite but dismiss MySQL when it's tiny bit off the SQL standard and people complain how PHP converts values with best effort guess on different types but not when SQLite does that too. Don't know why anyone would use SQLite in production except for as some KV store embedded in an app.
Earlier quoted context omitted.
SQLite is the most deployed database in the world
Not for this kind of applications. Same as Java being on 13 billion of devices, it doesn't mean anything if it's some config store underneath some mobile or desktop app.
Do you understand what kind of application Tailscale is? For all intents and purposes it's exactly what you described above.
Earlier quoted context omitted.
Excitement is only for people who are learning.
you should always be learning. and excited when you are. do you know everything?
Earlier quoted context omitted.
The cost of complication is high. They're optimizing for simplicity. Both for low friction development and easy operation. sqlite is amazingly simple for local dev. Probably even simpler than a json file. High availability Postgres is complex to operate (you need a whole separate strongly consistent data store to coordinate it). Cassandra is also very complex. sqlite is, again, simpler. Litestream makes sqlite plausi…
> sqlite is amazingly simple for local dev You are buying simpler local dev with a more complicated and error prone production. > High availability Postgres is complex to operate High available SQLite is complicated. More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system. Instead, you've got to bolt on solutions to fix the fact that you chose SQLite.…
How so? Any evidence for that?
> More complicated by the fact that SQLite wasn't designed at all around the notion of being a multi-tenant database system.
Neither was Tailscale, that's why the engineers decided they were a good fit. But I'm sure you know more about it than they do.
> Containers make local dev with postgres or other db technologies pretty slick.
No they don't. Dockerizing everything for local dev bogs you down to Docker's added latency for every operation, this is not even getting into the latencies added by having to periodically `docker pull`, `build` images, provision the disk space for the images, and maintain all that infrastructure over time. Compared to that, an SQLite database is basically nothing.
> All your dev tools defined in the docker file. Done, new dev installs docker and moves from there
Docker is not a good way to do local dev, overall. The entire point of local dev is speed of iteration. If you need a usable test environment, set one up in UAT.
> A backend database is not the right location for SQLite.
The SQLite team actually disagrees with you on this: https://www.sqlite.org/whentouse.html
> SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites)....Systems designers report success using SQLite as a data store on server applications running in the datacenter, or in other words, using SQLite as the underlying storage engine for an application-specific database server.
But again, I'm sure you know better than them.