YUM repository is now HTTPS-enabled and also contains .repo file to easily attach the repository to your server yum installation.
Almost all software packages (both binary and source ones) also were updated with their current respective versions.
1. It is overpriced for its performance - https://cpu.userbenchmark.com/Compare/Intel-Core-i9-9900K-vs-AMD-Ryzen-7-2700X/4028vs3958 - 70% difference in cost, 20% difference in performance
2. They have a whole bloody lot of critical vulnerabilities specific to them recently discovered, that when avoided ('fixed up') by CPU firmware and OS, drop the performance quite a lot
3. They change motherboard sockets every now and then on a whim, so further upgrade would not be easy
4. The good motherboards and chipsets for these are overpriced as well, everything else is just meek
5. They are technically inferior, manufactured at 14 nm process, while current AMD CPUs are at 12 nm and next generation coming soon would be at 7 nm
6. They drop frequencies of the whole CPU under heavy AVX vector calculational loads - https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/
7. They have a stable huge userbase of those who overclock, meaning buying such CPU second hand can result in getting a 'nicely grilled' one
8. Recently, there were certain reportings that declared TDP (thermal dissipation, which stands almost equal to how hot the CPU is) for the top class desktop CPUs may actually not be real - https://www.anandtech.com/show/13591/the-intel-core-i9-9900k-at-95w-fixing-the-power-for-sff
9. If you prefer just an integrated videocard in your laptop or even desktop, the performance of integrated GPUs is totally terrible compared to AMD - https://gpu.userbenchmark.com/Compare/Intel-UHD-Graphics-630-Desktop-Coffee-Lake-i5-i7-vs-AMD-RX-Vega-11-Ryzen-iGPU/m356797vsm401440
10. They usually have thermal glue under the lid instead of solder (although some AMD CPUs have this flaw as well, and some Intel CPUs don't), leading to bigger operating temperatures (so more noise from your CPU and case fans)
Everything written above is just a personal opinion, you should think on it twice and don't take any things from it at the face value too willingly.
A yum repository with builds of software needed to roll out your personal hosting platform based on my WebConfig project is now available.
You can find it at http://yum.alex-at.net/ where all the binary RPMS and their respective SRPMS are posted.
Please see README files here for more information.
The repository is not yet complete, but Apache/PHP builds are already there. Configuration files for repository is not yet available. WebConfig itself is not available as RPM yet as well, but in few weeks it all will be added there along with the WebConfig project page.
You can always find link to page about it on the main page as well.
Yeah, I remember about the blog. To be honest, I have a whole bloody lot to post last months, but due to another whole bloody lot... of work... I have almost no time to finish / post anything in clear mind.
Hopefully I'll post some more stuff including useful code and binaries here soon.
Probably most of us who tried to build some L2 tunnel over Cisco L2TPv3 implementation (L2TPv3 xconnect) hit the basic MTU issue in the tunnel. MTU seems to be heavily limited, and ICMP responses from routers inside the tunnel try to clamp it.
Here's some solution to the generic MTU issue I found when setting up L2TPv3 interworking ethernet mode tunnel between 1841 and 7200 G2 routers. Critical points of the solution are marked blue.
1. Set up xconnect as usual with interworking ethernet, using proper pseudowire class, L2TPv3 class and other parameters.
2. Make sure pseudowire ip path MTU is lower or equal to the real MTU between routers.
3. Set MTU on xconnect termination interfaces both sides 4 bytes higher than your desired tunnel MTU.
4. Make sure ip virtual-reassembly is enabled on router interfaces that are used to forward L2TPv3-encapsulated traffic (the IP 'uplink' interfaces between the tunneling routers).
5. Push TAGGED VLAN with your traffic to be tunneled over the tunnel. If you need to push multiple VLANs over tunnel, use QinQ. Set/remove this tag you use for tunneling on switches, neighboring routers or any other stuff you have.
Where does this come from: it was confirmed between 1841 (IOS 12.4) and 7200 G2 (IOS 12.2SR) that L2TPv3 tunneling implementation on G1 routers (G2 not tested) mangles anything with IP ethertype, trying to clamp MTU and stuff and dropping packets with DF bit set. But when ethertype is VLAN ethertype, it just passes traffic over, fragmenting L2TPv3 packets where necessary. This allows to carry any traffic with MTU just 4 bytes less than MTU routers interfaces are capable of, over L2TPv3 tunnel. IP DF bit also don't propagate to L2TPv3 traffic when carrying VLAN-tagged frames over L2TPv3 tunnel, so it can be used properly over tunnel without affecting tunnel traffic itself.
So if you just want to push general untagged IP traffic over the tunnel, push it into some trunk VLAN from nearest switch to tunneled port on router and receive the same way on the other side. If you want to push some tagged VLAN or set of tagged VLANs, just push them directly and receive on the other side of the tunnel. If you need both general untagged and tagged traffic, use QinQ on switches to put everything to be tunneled over L2TPv3 under some common dot1q tag, and receive the same way.
I'm not sure if all Cisco router models (especially G2) behave the same way, some may differ, but two 1841s/two 7200s/1841<->7200 are surely doing ok.