Coincidentally I'm working on FeebDB[0], which is similar but for Elixir instead. It can be seen as a replacement to Ecto (which won't work well when you have thousands of databases).
Mostly as a fun experiment, but also from the realization that every place I worked at in the past (small/medium-sized B2B startups) would greatly benefit from such architecture.
Yes, there are massive trade-offs to this approach, and the concerns raised in the comment section are valid. This doesn't mean the database-per-tenant is never worth it. There's a sweet spot for it, and if it fits your business/application, I personally would consider it a technical advantage over competitors.
My goal with FeebDB is to eliminate or reduce the common pain points of database-per-tenant, including:
- ensure there is a single writer per database.
- improved connection management across all tenants (e.g. only keep open at most 1000 DB connections, similar to an LRU cache).
- on-demand migration (all shards are migrated on application startup, but if a shard that hasn't migrated yet receives a request, it will first perform the migration and then serve the request),
- on-demand backups and replication (e.g. the library knows which shards were updated in the last X minutes, so it can trigger Litestream or similar on demand).
- support for enumeration of databases (performing map/reduce/filter operations across multiple DBs)
- support for clustered deployment with "pinned" tenants (for now I'm assuming the IOPS of a single beefy server should be enough for all use cases, but once that's no longer sufficient you can have "shards of shards")
I think we are beyond the "theory" phase by now. Just yesterday I saw the president of a country advertising the products of a private company (Trump making an obvious marketing ploy for Tesla).
The failure relative to the original expectations seems to be that the other branches of government aren't fighting to retain their authority because the things they're being overridden to do align too well with what they would do themselves.
> the president of a country advertising the products of a private company
I think you're inventing new norms. It has never been unusual or interesting for the president of a country to do PR for some company in their country that has hit a rough patch (as long as this isn't a legal rough patch.)
Most of what our diplomats do is sell US products to other countries. They certainly have always played favorites.
> How can this ever be acceptable?
The horror. What if he says that he's going to Burger King?
(PS: they opted to go in a direction where it also includes some media-related features -- like tracking movies or books you've seen/read -- but this can be disabled).
If you navigate straight to bad-domain.com which redirects to good-domain.com, there will be no referer at all.
If you click a link on red-herring.com which points to bad-domain.com, which then redirects to good-domain.com, the referer will be red-herring.com (if not disabled entirely).
I just tested on firefox and it doesn't send the "Origin" header when using referrerpolicy="no-referrer". It's also not present when navigating using the url bar directly.
I didn't say it was. Browsers display an alert when full-screen mode is activated. Full-screen mode isn't a security feature, but the browser does something the website developer can't control so that users can conclude that something fishy isn't going on. I think the ability for one website to hide that they've redirected to another is a vulnerability.
I'm inclined to agree that websites should know when they're the target of a redirect but that has nothing to do with Referer! That header does not work the way so many seem to think it does. As I've laid out elsewhere in this thread, HTTP redirects do not show up in Referer under any circumstances. Right now, one site doesn't have to do anything to "hide" that it's part of a redirect chain, since there's no tracking of that chain to begin with.
Additionally, a break might be an opportunity for your mind to continue working on whatever it was you left off with, whereas an interruption explicitly redirects your attention to another topic.
When I’m deep in the weeds on a task, stepping away for a walk in the park, a workout, or to prepare a meal or some coffee, affords me the opportunity to clear the micro details of the task from my mind while retaining the macro at the tip of my attention. This state is very frequently where the best insights on the task emerge, whereas an interruption resets both micro and macro attention entirely to something else.
A hobby project of mine (in Elixir) uses SQLite as primary database. Each test runs in its own fully isolated SQLite database. No mocking (or transaction rolling back) needed. Most of these tests take less than 1ms to run (and when they take longer, it's because of something else).
This kind of setup makes the usual Ecto Sandbox approach feel slow, but I do agree that the way Elixir approaches this is great!
I actually have two projects that use this approach, FeebDB (which is the library I wrote to manage a "one SQLite database per client" approach) and HackerExperience (a game under development that uses FeebDB).
The overall idea is simple:
1. Before tests start running, create a prop of each database.
2. The prop contains the "starting database" for each test. It may contain seed data (optional).
3. For each test, copy the prop and assign it a unique shard identifier (say, cp /props/user.db /test_data/user/874125.db).
4. The test knows the `shard_id` and can do whatever it wants with it; no one else will bother it.
5. Once ExUnit is finished, delete all shards.
Both projects follow a similar approach (I wrote it first in FeebDB and copied into HackerExperience, which has some sections commented out -- I need to clean up this part of the codebase).
For both projects, you will find steps 1/5 in `test/support/db.ex`, step 2 in `test/support/db/prop.ex` and steps 3/4 in `test/support/case/db.ex`.
> Do I need 2 replicas to avoid the split brain scenario? my brain hurts already.
It will hurt even more.
The recommended way is to set up a witness server. Yet another thing to manage in a properly designed Postgres cluster. Certainly not an easy/trivial thing to do, ops-wise.
From [0]:
> By creating a witness server in the same location (data centre) as the primary, if the primary becomes unavailable it's possible for the standby to decide whether it can promote itself without risking a "split brain" scenario: if it can't see either the witness or the primary server, it's likely there's a network-level interruption and it should not promote itself. If it can see the witness but not the primary, this proves there is no network interruption and the primary itself is unavailable, and it can therefore promote itself (and ideally take action to fence the former primary).
An interesting acronym you'll hear is STONITH (in order to fence the former primary).
> Currently, FreeBSD lags behind in key areas such as [...] laptop-specific functionalities like suspend/resume
Many years ago I migrated to FreeBSD and absolutely loved it. I was forced to migrate back to Linux once I started a job and ended up staying with Linux to this day.
A few months back I decided to give FreeBSD another shot. The one thing that was an immediate deal breaker was being unable to suspend/resume on my desktop computer. For my workflow, that's an unnecessary waste of power / energy.
Just wanted to share this testimonial to outline the importance of suspend/resume for non-laptop hardware. Almost every time I see this discussion, it's focused on laptops.
By the way, I'm extremely excited about this initiative to make FreeBSD more attractive to non-server users in general (not only new ones). That will surely be a huge benefit to the entire community. If I can't run FreeBSD on my machine, I won't runt it on my servers.
Am I the only one that never uses suspend/resume? If I'll be away from my laptop, I save everything and shut it down. If something is running, I plug it in and lock the screen.
I did, routinely, with my ThinkPad until a month or two ago. See, it would surreptitously turn itself back on (to hit Windows Update!) and kill its battery overnight. I tried turning everything off; didn't work.
Just over a month ago, https://news.ycombinator.com/item?id=41442490 was posted. I went into the BIOS, changed the "sleep mode" to "Linux" (at least ThinkPads still consider this), and... in sleep mode, I lost about 2-3% of battery overnight. Tops. I still hibernate for most situations, as I don't use the laptop much, but when I know I'm going to be using it often, it's nothing, and it works the way things were supposed to.
The regressions in standby/suspend are staggering inthe last 3-5 years. Peak stability was with my t480s, just proper s3 support. Currently it's hit and miss with this silly s0ix shenanigan.
Idk about “the only one” but surely that’s rare. Why would you want to take the time to save, quit, reboot, and reopen everything instead of closing your laptop which takes less than a second?
I used to do the same, but being able to put my laptop on a shelf for a week or two and get back to what I was doing is really convenient. It's basically as if you had instant fast boot with no downsides.
Since getting a MBP I'm not shutting it down. Not sure what magic they are doing (some very deep sleep) but shutting it down't is absolutely not needed... When I step away I just close the lid and then open in it 1h or a couple of days and have everything as it was ready to work in split second...
Suspend-to-disk does pretty much that - it saves the contents of your RAM to swap. Suspend/resume should be transparent to most applications, perhaps excepting those that rely on a real-time network connection.
I mostly live in the windows world, and since at least Win 7 its sleep and hibernate have been reliable enough that I use them regularly. When I'm deep into a project for work I can easily have a dozen apps open. Having to reopen them multiple times a days is (to me) just a waste of time when sleep works great.
I only use suspend/sleep because it's much faster to get back to what I was doing. If I shutdown I have to open everything again and some things (Fusion 360 for example) take a good 30-60 seconds to open the program and documents and be in a usable state.
I run xubuntu as my main os on my laptop for many years now and I never suspend. Always full shut down.
I do let it sleep when plugged in but that's just sleep not suspend/hibernate. So on my desk at home it's usually just a mouse wiggle to resume where I left off. But when I shut down it's a shut down.
I don't know why people say it's some kind of deal breaker neccessity. I have it available and don't use it.
I would just never turn off my computer if I had to do this. It’s far too much effort. I much prefer suspend, it’s a nice compromise between power saving and convenience of always on
Why not? I can’t see any reason to waste time booting when your computer can be ready to go in an instant, with everything you were working on undisturbed.
Nope, I don't see the point now that we have SSDs and fast boot. Browsers, IDEs, even stuff like Notepad remembers where it was after a reboot so it's not like you'll lose any in-progress work you couldn't be bothered saving.
I disagree. There are still tons of apps that don't "save state" exactly where they left off, including browsers. I absolutely dread restarting every time I am forced to do it for kernel updates, because that means I have to re-open all the same programs and navigate back to where I was again. And I don't like saving any browser history so that means re-logging into a handful of sites, doing the 2FA dance etc etc., it's really a big hassle.
If you have chosen not to save your browser history then obviously the history will not persist - the feature you opted not to use has been disabled as designed. If you set your browser up to have persistent history (the default for all mainstream browsers) and ensure the option to restore tabs on browser restart is enabled (I think also the default nowadays due to rise of mobile) it really does just work. Worst case after an epic crash that even the browser itself doesn't recognize Ctrl-Shift-T will get you back, even if you had dozens of open tabs in multiple windows, even after a reboot.
For other stuff, if you always have the same set of programs open and always put them in the same place, your window manager should restore that for you after a reboot on UNIX. It's been two decades since I used X frequently but even back then window managers could pin apps to fixed screen positions. On Windows default positioning has often been a bit less predictable, but there are custom window managers there too if you really want it. In any case the default window manager has plenty of keyboard shortcuts to very quickly open and arrange apps how you want them.
My work laptop boots to logon before I even get the charger, mouse and monitor plugged in, and after typing my password I'm back with my browser and IDE running, VPN connected, WSL up etc in less than a minute, usually while still mid smalltalk/greetings with my colleagues.
With the move to cloud-saved everything and the expectation of users that all their data should always be synced across all their devices, you need to go out of your way to find and/or configure apps to not automatically persist settings and state these days. For some apps I make that decision deliberately because I don't trust the middle man (e.g. bookmarks and tab sync) but that's a personal choice I make to forgo convenience for privacy. If the FreeBSD (or Linux) desktop experience is not doing this kind of stuff out of the box, then I think that's one of the first things it could do to meet the expectations of people coming from Windows/Android.
From my perspective suspend/restore is perhaps fine if your laptop never leaves the office, but I usually find myself more annoyed than delighted when it kicks in by accident. Your battery life starts to hinge on literally the efficacy of your laptop's physical hinge, which if you bash your computer around a lot during commute is less dependable than an on/off switch. And nothing worse than having your back suddenly get hot because your laptop decided to wake up while you're cycling in multi-lane traffic, especially if your morning schedule has you in meetings instead of charging at your desk.
In general I disagree with what you're saying, there are still tons of programs that don't have any cloud syncing, plus not everyone wants to use that. There's also many WM/DEs that do not re-open running programs or keep window positions, including basically all the ones I use. Plus I also run many programs as different users, for privacy/isolation purposes, which no DE can handle in that case.
I also have historically (and still) had major issues with suspend/resume when a discrete GPU is involved or some other hardware device that linux can't resume properly, I always end up having to just reboot anyways which defeats the purpose.
> If I can't run FreeBSD on my machine, I won't runt it on my servers.
How does offering a laptop or desktop OS experience relate to being a great server OS?
Anyway, the last time I was using FreeBSD on a client was in the late 90s. I am still running FreeBSD servers. It never bothered me that running that particular OS on a laptop maybe could be a challenge. The FreeBSD project has limited resources in terms of money and developers and I'm quite content seeing that going towards building a great server OS.
Diverting people and money towards a better laptop support just means competing with Linux and I don't see FreeBSD bringing something really compelling to the table. At best it'll just do everything Linux already does.
I use to be a FreeBSD user ages ago, but stopped at v5. I tried again at v8 and loved it, but back then I had to remove it due to disk space.
But one think bothered me. They love to patch some packages, a notable one is ssh. I wish at least in that case they trust the OpenBSD folks :)
But one thing I like a lot is jails and I had a jail for GIMPS and an ssh portal to transfer files to/from work. I think jails are much better than Linux docker and friends. I wonder if creating jails have gotten easier since v8 ?
Now all I have is laptops, and I have stayed away because of I heard of poor laptop support. I toy with giving FreeBSD a shot again, but will wait for the outcome of the Laptop project they started.
> I wonder if creating jails have gotten easier since v8?
I think iocage was released after v8, so yes, definitely! Not only creating, but managing jails as a whole. In many ways, iocage can be compared to docker when it comes to container management.
It really depends hard on the quality of the systems firmware, i.e. the BIOS/UEFI, no matter if laptop or desktop/thinclient.
I recently got some obsolete/EOL thinkcenters for homelabbing fun. They do S3(suspend to RAM) with everything I've thrown at them. Even most exotic stuff like https://genode.org/ (though only running 'live' from the USB-Image that they offer, didn't install so far). FreeBSD did it, NetBSD did it, various Linux Distros did it, without exception. The one currently running does it, too, without having had to setup anything.
Be it via the little power-button on the front, or some hot-key combination choosable from the UEFI, OR simply another hot-key delivered by the keyboard. In my case that blue thing between ALT-GR and right-CTRL+F12, then slapping any key afterwards turning it back on. (might by undesirable if you have cats, kids, whatever)
Anyways, WITHOUT exception! I did try this like mad, off'n on off'n on like a stroboscope, at least a 100 times.
One of the problems with suspend/resume is simply: nobody is looking at it or trying to improve it. There is no progress because nobody has tried. The current recommendation is "if suspend/resume doesn't work, disable all of the drivers until you work out which one (of many?) is causing the issue, and work on a fix - sure, people could do that, but most won't - and not even knowing which driver is the issue is annoying.
Until recently, rc scripts (think initd on Linux) had functionality that could be executed on system resume, but not on system suspend - like stopping a service on suspend. Why? Simply because nobody added that functionality for ages [0].
Similarly, drivers often have suspension but not resume capabilities (why?) which means they need to be added by someone who actually tries to use suspend/resume. [1] is an example of this (around midway through the section).
I recently took the time to get FreeBSD set up on my MacBook Pro from 2015, and it took quite a few kernel patches to get it working - many of which I don't think should have been missing already [2].
Webcam support is another issue; at the moment, webcamd is unmaintained because the developer passed away. Even then, it is just an emulator for Linux's USB subsystem and relies on some random person's GitHub for v4l2-loopback support using a branch called "my-build"[3].
Wifi is also an issue, with the best option for fast wifi support being the usage of a nano Alpine Linux VM, and using Linux's drivers [4]. If your wifi device is even supported, it's probably quite slow.
If all three of these things ever progress, I can see FreeBSD being more accepted by the masses. It is a great OS, but for personal computing, there are clear issues.
Suspending desktop systems is unusual, but these days traditional ACPI S3 (and S4) suspend is missing from more and more systems in favor of the far less efficient modern suspend just so your notification terror continues around the clock.
I think what FreeBSD and any other systems need is either compatibility or something similar to NixOS. Declarative systems management seems ripe for BSD derivatives.
But it has to be done right. As much as I love GUIX for example, GUIX is hampered by not being able to support a lot of hardware by design.
Mostly as a fun experiment, but also from the realization that every place I worked at in the past (small/medium-sized B2B startups) would greatly benefit from such architecture.
Yes, there are massive trade-offs to this approach, and the concerns raised in the comment section are valid. This doesn't mean the database-per-tenant is never worth it. There's a sweet spot for it, and if it fits your business/application, I personally would consider it a technical advantage over competitors.
My goal with FeebDB is to eliminate or reduce the common pain points of database-per-tenant, including:
- ensure there is a single writer per database.
- improved connection management across all tenants (e.g. only keep open at most 1000 DB connections, similar to an LRU cache).
- on-demand migration (all shards are migrated on application startup, but if a shard that hasn't migrated yet receives a request, it will first perform the migration and then serve the request),
- on-demand backups and replication (e.g. the library knows which shards were updated in the last X minutes, so it can trigger Litestream or similar on demand).
- support for enumeration of databases (performing map/reduce/filter operations across multiple DBs)
- support for clustered deployment with "pinned" tenants (for now I'm assuming the IOPS of a single beefy server should be enough for all use cases, but once that's no longer sufficient you can have "shards of shards")
[0] - https://github.com/renatomassaro/FeebDB/