I'm on Debian stable, not OpenBSD, but SpamAssassin + razor + pyzor works really well. Roughly 1 spam per month, and 1-2 false positives a year. This is for an email address that has been used and openly spread widely for 25+ years.
The real work is making sure that outbound mail gets delivered, but even that is just making sure you have a clean IP and setting up reverse DNS + DMARC/SPF/DKIM...
Nice never heard of those until now. Link for anyone here cause it's kinda hard to google razor email filter for some reason. What does that setup have over amavisd?
I understand and respect this opinion, but it is clearly not true that you need "years of carefully built reputation" as per my own write up in this thread and plenty of others here and elsewhere. Still, I do respect and understand that e-mail is a particularly nasty hole to dive into with potentially serious consequences so I do not look down on those that bow out and go for alternative solutions.
He means the top part above Google suggestions. If you type a url or company name Apple sometimes guesses the url and provides a direct link. Google not involved there - only if you click a Google suggestion or hit search/enter or whatever
MacOS in 2000 was still old MacOS, with no compositing at all. The NeXT derived version of MacOS was still in beta, and I tried it back then, it was very rough. Even once OSX shipped in 2001, it was still software composited. Quartz Extreme implemented GPU compositing in 10.2, which shipped in 2002.
Windows finally got a composited desktop in Vista, released in 2007. It was GPU accelerated from day one.
MIPS had a fully classic RISC MMU, TLB only. TLB miss resulted in a fault which the OS handled to walk whatever data structure they chose for memory mapping. They had the KSEG regions which let the (virtual mapped) kernel easily access physical mapped memory for the walk. Not sure if this changed with MIPS64, though KSEGs would have been much less costly in terms of address space there.
PPC (at least Book-E variants) had a more complicated setup where TLB misses did a hash table lookup in HW. If that missed as well, it faulted to the kernel to do the full walk. The trick PPC used was that the page fault handler ran with paging disabled entirely, so it could access physical memory directly while handling the miss, no KSEGs necessary.
No idea how SPARC handled this, but x86/x86-64/ARM all do this entirely in hardware, though in practice it is really microcode.
Can you provide some citation for the claim that x86-64 (assuming something modern like AMD Zen or Intel (post) Skylake P-core) does page table walking/TLB-filling in microcode instead of the fairly obvious state machine that can walk as quickly as the cache hierarchy can deliver the table entries? Well, maybe give it a full cycle latency to process the response and decide the next step, though I don't remember there being any addition required to generate the address of the next level's page table entry so the bit of combinatorics to control the cache's read port might fit in the margins between the port's data out latches becoming valid and the address in latches's setup deadline.
For the moment some random cheap ones from Amazon - I haven't run it long enough to see if it will last more than a few months of full-time use. The battery was a freebie, so I don't actually recommend it; the charger is an "ULTRAPOWER 4a". We'll see.
What it's augmenting is a pretty cheap AIMS power brand modified sine-wave inverter/charger (meh, should have gone pure sine, it causes some of the power supplies to make funny noises) hooked up to a Litime 2kWh LFP battery (very happy with the big battery). TODO on the experiment is swapping out the inverter part with direct 12V conversion for some of the things on the inverter, but I wanted to test the regulator approach with a non-critical component for a month or two first before hooking it to something that can deliver 100A, obviously with a fuse. :-)
WoL relies on a special magic Ethernet frame being sent to the MAC of the sleeping computer. A normal ARP or TCP SYN from an incoming HTTP request won't do it. The wikipedia article has the exact frame format:
https://en.wikipedia.org/wiki/Wake-on-LAN
I've seen setups where the router is configured to send the magic WoL packet when it sees an ARP for the IP of a computer it knows is sleeping, but you'd almost certainly know if you had an exotic configuration like that on your network.
The terminology here can be a little confusing, because WoL isn't a precisely standardized term but rather sort of a general label for a family of behaviors, the most common of which is the "Magic Packet" that originated with AMD. For some time a magic packet was mostly the only thing that could wake a computer, because the NIC had to originate a power-on event and most NICs were only capable of doing so in response to a magic packet. There were, though, particularly in more "enterprise" contexts, NICs that could be configured to wake the machine on other types of traffic. This kind of thing went in the option ROM of high-end NICs.
Today, though, with various low-power states and "hybrid sleep," packets received while in a low-power state can actually be delivered to the operating system to make a decision on waking. That's made WoL a lot more complex: with a supported network adapter and power state, Windows will wake up in response to pretty much any network traffic directed at the sleeping computer. That detection is surprisingly sophisticated, unicast packets addressed to a computer will wake it, but so will certain recognized discovery protocols sent to broadcast when they specify the computer's hostname.
One the one hand, it's pretty neat that e.g. attempting to connect to an SMB share on a Windows computer will wake it. On the other hand, it means that "nuisance" WoL has become an occasional irritation. For that reason you can configure Windows back to the original behavior of only waking on a magic packet specifically. To be fair, the whole idea came about in part because of all the implementation limitations with magic packets that made them very flaky.
Microsoft refers to all of this functionality with the term "WoL," while Apple seems to have decided to avoid the confusion by calling the entire concept "Wake on Demand" instead.
It's written for Cumulus Linux, but it should be adaptable to other NOSes with some work: https://github.com/CumulusNetworks/ptm
You give it a graphviz dot file, and it uses LLDP to ensure that reality matches that file.
reply