I do. It's nowhere as hard as everyone on here makes it out to be. And I don't even use an easy solution like Mailcow.
Spam is a solved problem with rspamd, and it's not even an llm
That is the exact problem that got me to abandon my splendidly working, self-hosted email stack. I had so many instances of mail just not getting delivered, despite doing absolutely everything correctly, that I gave up.
Thankfully not a problem we've encountered yet. All my mail is DKIM signed, SPF aligned etc. I also registered on dnswl.org which is a signal quite a few people seem to use.
I’m wondering what the most fool proof way to get a message delivered to someone else is. I found out today some SMS messages I sent were silently dropped. Email doesn’t always get delivered. I would hope the closed ecosystems like Signal and Whatsapp are better at this and in any case you need both parties to agree on a channel. I just like email because my identity is maintained even when I switch providers, and nothing else quite like that exists.
I still handle email for multiple small businesses (for over 20 years) and recently switched from the mailscanner+spamassasin to rspamd and the scanning is so much better/easier now
my backend is still dovecot+postfix, still works beautifully. I am able to run rspamd+dovecot proxy on a small vps and the storage is handled by a backend office server with dovecot. If VPS has an issue can spinup another easily/anywhere and backend is also virtualized (libvirt) so easily restored (with multiple backups in multiple places)
biggest thing to worry about with deliverability is ensuring your SPF and DKIM (opendkim) are correct, which is not too difficult and rspamd is able to handle the dkim signing/verification which is nice
Yup rspamd being able to do the DKIM signing was what made me move from spamassassian+opendkim to just this single solution. The web GUI and its speed were just really nice extras it brought with it. It's one of my favourite pieces of open source software.
Personal mailserver sorry. rspamd stops all the sent-using-my-from-address "i hacked you" emails (DMARC drops them) and all the other random spam stuff. I can imagine though a large business with thousands of email accounts it wouldn't be as easy though.
Of course. I wish that Immich had existed when I started using Google Photos, but it didn't. And I'd just had my first child so I really wanted to ensure I didn't lose any memories.
These days I run the two in parallel.
Plus friends and family inadvertently give Google/Facebook (etc) your personal info via tagged photos, contacts, DMs without your consent and they gather/link/sell this collateral info to the highest bidder without anyone being the wiser.
Sure, but that's not the same thing. How they use the data is the important part. The google photos are not to be used for security for example. Different ToS.
We should try and not have a defeatist attitude and fight back as much as we can
Because Plex worked amazingly ~5-6 years ago, while Jellyfin was still very early stage. It'd sort of work. So there's a lot of "Well I'm already using Plex" inertia. Plus Plex has very lovely, polished clients, you can easily invite people, share your library with others etc etc. Once they got all that of course, then the changes/fees/ads/bloat started.
Jellyfin is great, it's all I've ever used. But it's still very rough - AppleTV support is limited+buggy (ask my wife...), you can't cast to a Chromecast from iOS etc. Plugins are required for some things to work. Transcoding is harder to get working. Good luck downloading stuff for offline use on the mobile client apps, all you get is the raw movie/tv show file - you have to use VLC to play it.
Again, I love Jellyfin and I use it daily. But we're both kidding ourselves if we think the polished experience you get with Plex is the same as it is with Jellyfin.
Indeed. I'm a member of a few music trackers and they have a lot of great stuff, but What's archive was amazing. One of my proudest things I own is a What.cd beer cooler I bought from them.
Thank you. I have this discussion all the time. The argument I get back "Right, but it seems like the change takes awhile because of the DNS cache expiring, so it's the same as propagating". My counter to that is to say "If I punch you in the mouth, would you just tell people I'd asked you be to be quiet, or would you use the right explanation as to what'd happened?"
(It's a stupid counterargument, btw, but it ends the discussion)
Just FYI, those discussions might be ending because your analogy comes across as a threat to punch them in the mouth, rather than because it convinces them.
But is there a functional difference between push and pull in this case? Is there something that cannot be explained in terms of propagation? Perhaps timing: there's no reason for propagation to wait an hour or a day.
BTW, only last week I explained a potential problem of a DNS change with caching, and it was understood. There doesn't seem to be a need to simplify it.
There is absolutely a reason for propagation to wait an hour or a day, and you've set that value in the TTL field for the record in question. It stands for Time To Live and specifies how long downstream resolvers should cache the last value they saw before querying the authoritative server again, if you set that value to a few seconds then almost every DNS resolver in the world will get updated values within a few seconds as they expire the cached value.
This floppy decompresses the entire initrd image into memory at boot, which "wastes" memory compared a proper install on a HDD. You can also lower memory requirements further by enabling swap.
A floppy distro (especially one relying on a compressed initrd) will inherently require more memory. And I suspect the maker of this distro is using a different definition of "minimum" than we would have used back in the 90s (closer to "recommended").
However, it looks like modern linux kernels just require more memory; The kernel binary is certainly larger, floppinux is spending an entire 888KB on it's very stripped down modern linux (doesn't even have networking enabled), while older floppy distros using 2.2/2.4 kernels keep it under 512KB (with networking, and a bunch of other features.
Also the goal was to run LATEST kernel with no changes - just config. With other compression algorithms it was impossible to fit everything into a floppy. And I really wanted to have nano and some space to save few files. Without this it would be totally not usable OS.
Yikes-- bringing back memories of frustration. X11 on my 486SX w/ 4MB was excruciating. It would swap like crazy. Adding 8MB more RAM made such a difference. Kernel compiles were much less swappy, too. (I can still the buy I bought the four 2MB 30-pin SIMMs secondhand from but I can't remember how much I gave for them in 1993 or 1994. I feel like it was more than $100, though...)
The Compaq laptop I was using had a 486SX and 4 MB of RAM. It had a 640x480 (if I remember correctly) screen and I'm pretty sure the framebuffer was in a separate video RAM that was not counted in that 4 MB. Used to type a lot of LaTeX on that laptop and used X11 for previews - xfree86 even had a special driver for the specific video hardware that laptop had. Not sure if I used a window manager. I think I just pointed ghostscript at the X11 screen from a text-mode console.
Indeed. So far as I recall I had a greyscale monitor that couldn't do more than 800x600. I think it was a 486sx and I probably still had a 32GB MFM hard disk at that point so it was a very underwhelming machine.
I think 1MB of RAM in a simm was about £100 at that point, but it's been a while!
I had 2.2.x running on my 386 last year in 4MB. Not enough for a full GUI though but enough to set up TCP/IP and Samba to image a drive over the network.
8MB, at least in an emulator, can run a basic Xterm but not a lot else (though it'll happily run as a remote X frontend for a more powerful machine over Ethernet, it was fun to see it try to render Gimp 3 running on my desktop lol)
My 16MB 486 had no issues with a full IceWM session (this was kind of my hacked version of BasicLinux which itself was built on a ~2000 version of Slackware)
I'm going to guess from the size of the kernel, since for distribution it has to be a fairly 'generic' kernel with just about every driver built into it. If one were to compile a custom 6.14 kernel for a specific hardware target with only 1 model of NIC (3c509b for example), etc, it could be a lot smaller.
If it's compiled into the kernel it'll occupy memory regardless if it's being used. If it's built as a kernel module then it doesn't occupy memory until loaded.
I think you could run 2.0 + X11 in 4MB in a pinch. I know I ran 2.2 + X11 in 5MB on a cast-off i386SX; tight but useable. If I recall right, 2.0 & 2.2 would run in 2MB without X11 (but a GUI like MGR might fit). 8MB was pretty good and 16MB was positively spacious.
Edit: Add: 2MB/4MB boot with a stripped down kernel, not generic.
I got 2.2 with BusyBox to consume ~2200K at boot after a lot of fiddling. Left me plenty of user space for doing command line work on my 4MB 386; i mentioned in another comment though, X was only really useful as a remote terminal in 4MB, to run a local program via X pretty much required 8MB. But pretty sure i got Doom running in X on 8MB...
I did all these experiments a year or two ago. I lost most of my work due to a hard drive failure (the one in my workstation, not the 386 lol) but all the surviving work is on my github:
reply