If you want to keep repeating this fine, but at least keep up with events.
It means you've routed out your ISP through a peering point that isn't Level3, and that the peering point between your VPN provider and L3 is less saturated than your ISPs. That's all it proves.
I'm afraid that possibility has been discounted. Netflix has paid up. Didn't you get the memo?
Thus, if you are connecting to tcp/25, it is safe to assume, in this day and age, that you *are* an MTA.
Nope, it isn't safe to assume that. If that was the case then this traffic would be blocked completely, but it isn't, and what's more it is being modified. Do read the article.
When the original article cites as its first example of network tinkering the already thoroughly debunked "faster Netflix through my VPN" video, the level of technical credibility to the article is already set at "abysmal". There's no argument that the VPN tunnel was faster (obviously), but the alleged reason (which many sites, including this fine establishment, got on the bandwagon for, even though they should know better) was horseshit.
It's really quite simple. If you have a download speed topping out far lower than your maximum and you then connect through a VPN and get more available bandwidth then there is a rabbit away somewhere. Netflix have already now paid up anyway to get rid of this 'issue' for their users, so that debunks this bit of dog shit.
Second, the article demonstrates the problem with a connection to tcp/25. Unless the customer is running a mail *server* on their residential ISP line, they should be connecting to tcp/587. The wireless provider in question here is absolutely within their bounds to say "they don't want you running an SMTP MTA on the wifi", but that running a normal MUA is fine. Is there any evidence that this problem also exists for connections to tcp/587?
Connecting to something on port 25 and allowing inbound connections to something you have running on port 25 are two entirely different things. If you don't know that then you really don't know anything at all and frankly aren't qualified to comment.
Syslog facility does continue to function, but not in a way you are implying. Not independently. Journald must forward stuff to syslogd.
Exactly. I'm getting tired of hearing that things will continue to work in the way they always have when this issue comes up. They won't.
Oh, and I can already search my text logs in a 'fine grained' and searchable manner thank you very fecking much. I know that might come as a big fricking shock, but a lot of people are.
If he believes he's going to take on Linus and the kernel developers, stamp his feet and take over the Linux landscape he's going to lose badly.
i was asking about software you wrote as you are the one moaning.
Questioning someone's ability to write software or telling everyone to write a patch knowing full well they either can't, or it won't be accepted if they do, is right up Lennart's alley. Is that you Lennart?
Troll? For pointing out that networkmanager, pulseaudio and systemd actually work?
You sound surprised. However, they all still have longstanding problems which their developers have a long history of passing off.