You mean a developer who finally brought seemless audio switching to Linux bringing it in line with other operating systems from the late 90s?
No, we mean a developer who took an audio system that just about ended up working through the days of OSS and ALSA, broke large parts of it, shrugged his shoulders and said that a lot of kernel drivers that used to work and were now largely unmaintained needed to be 'fixed' rather than maintaining a completely sensible approach of maintaining backwards compatibility. PulseAudio has now only improved since he started turning his attentions elsewhere.
That's called progress. I liked MySpace and didn't like the switch to Facebook. So what?
People switched to Facebook largely because MySpace was crap, nor was it an enforced change. People voted with their feet. How and why are we moving core and very important pieces of software in Linux distributions to systemd again?
There is no catch-22. Gnome is led by RedHat. RedHat is moving in the direction of OpenShift. PaaS vendors want process management i.e. systemd. That's a clear cut chain of dependency.
Good luck to them, but that has no relevance to other Linux distributions or those administering them. Again, this argument of "Red Hat is doing this therefore you have to" holds no water and whenever all else had been exhausted that's what we get. I also wish them luck with the inevitable security problems because they are going to be humdingers even if you had a bunch of maintainers who were extremely responsive to bugs and had a clue what they were doing.
Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.
You have no point at all apart from making a whole load of noise to make it look like you have one.
At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary".
Not an argument I'm afraid, but this is the kind of non sequiturs that systemd critiques usually boil down to once its proponents have exhausted all the nonesense.
Sys admins demand logs they can read under as many circumstances as possible and the ability to take logs off a machine promptly in the event it is compromised. systemd fails conclusively on both counts. The point, and the end.
You mean a disconnect like the fact that you can pretty trivially 100% a couple of servers running feature extracting daemons processing text based logs at the moment for a small cluster of machines?
I have no idea what that load of claptrap means (par for the course with this trail of systemd brain damage), but you obviously don't understand the importance of a push based system. You want to make sure stuff gets pushed as soon as reducing any possibility that logs get altered inbetween. The fact that anyone suggests pulling as a solution means that have no clue at all about system administration.
Where has this absurd notion that text logs are efficient come from?
Fucking hell. The issue here is lowest common denominator. Under as many disastrous circumstances as possible there are those of us who, you know, do fucking administration for a living who have to be able to read log files - and I mean have to. To put a binary logger in the middle of there means there are those of us who can use half a brain cell and work out why that would be a problem. That's the real elephant in the room, but I notice you throw the strawman of efficiency in there.
Of course rsyslog also reads systemd journals natively.
In the past to get network logging you needed to install a syslog daemon. And with systemd you still need to install a syslog daemon. What's the big deal?
Have you stopped to think how utterly stupid that statement is? In the past I had syslog running as default. No work necessary. Now I have to run it as a separate daemon from the 'default' logging system just so I can get plain text logs, hoping systemd doesn't corrupt anything inbetween.
If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.
Under no circumstances has systemd been supported on technical grounds (those proposing it keep repeating this ad nauseam in the hope it will just be accepted as fact), nor has there been any extensive discussion in the manner he describes. systemd has been imposed as a de facto default almost overnight and the general consensus has been that it would be accepted with nary a whisper. Now that there is some pushback various characters are getting upset.
Given that this is an extremely core piece of software that a distribution is going to have to support come hell or high water it deserves a huge amount of scrutiny it hasn't got. You've also got to look beyond the code and ask yourself whether it is backed by a group of developers who are very, very, very responsive to security issues and bugs. The answer to that is a big fat NO.
"But desktop environments like Gnome were already requiring systemd before Debian switched to it; Debian cannot hold back the tide."
In every supposedly technical discussion that I have seen about systemd this is the default end argument. That is NOT a technical argument.
Wow, another long post on systemd spouting ideology and rhetoric without nary a valid technical complain....but the project also aims to provide lightweight implementations of what it considers "core" functionality.
What a load of ideological and and rehtorical claptrap.
None of my systemd systems use systemd cron or DHCP for example, even though those daemons exist.
Ahh, yes. Cloud stuff. Where you are processing a lot of data and where your processing and I/O resources are not your own. I always laugh at people who say "Oh, we don't need all that infrastructure stuff" and start moaning "Oh, why does it cost so much and why do we have to spend so much more when we add data?" Not to mention putting your important data on a platform that is financially questionable, has outages that providers simply don't care about and where it's going to be one hell of a PITA to move at any time later owing to the amount of data.
I'm afraid this is crap no matter how you word it. Verizon themselves attempted to debunk this, and they ended up not doing so. What's more, they've paid. The end.
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.
I can't mod you up any further, but yer, you're spot on. This is actually the default behaviour of a lot of routers. It might look like malice but in this case it could very well be complete laziness and a lack of awareness. Typical ISP in other words.
I'm afraid it's become clear that Lennart has a lot of very serious personal and possibly mental issues that mean he just isn't suited to working with others. The progress of systemd will mean that eventually there will be a serious conflict with the kernel developers, amongst others.
It's exactly the kind of misdirection and smoke-and-mirrors you get from the systemd crew every time a serious shortcoming is brought up. It's a pretty serious mental issue. Oh, and yes, having to deal with a corrupted Windows Event Viewer is exactly like this is going to be. Something you should just not have to deal with.
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.
It's a Lennart Poettering meltdown and accurately exemplifies the problems people have with him, those around him and why people are justifiably concerned about the software he is being allowed to write. This guy simply has 'issues'.
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.
Slashdot Mirror
Systemd will forward to syslogd if you want it to so you can still use your standard tools to view the logs if you want.
Not an answer.
many administrators of Linux installations do not want any of Poettering's libs installed at all.
Insane.
Not if you understood what that software does or his past history.
You mean a developer who finally brought seemless audio switching to Linux bringing it in line with other operating systems from the late 90s?
No, we mean a developer who took an audio system that just about ended up working through the days of OSS and ALSA, broke large parts of it, shrugged his shoulders and said that a lot of kernel drivers that used to work and were now largely unmaintained needed to be 'fixed' rather than maintaining a completely sensible approach of maintaining backwards compatibility. PulseAudio has now only improved since he started turning his attentions elsewhere.
That's called progress. I liked MySpace and didn't like the switch to Facebook. So what?
People switched to Facebook largely because MySpace was crap, nor was it an enforced change. People voted with their feet. How and why are we moving core and very important pieces of software in Linux distributions to systemd again?
There is no catch-22. Gnome is led by RedHat. RedHat is moving in the direction of OpenShift. PaaS vendors want process management i.e. systemd. That's a clear cut chain of dependency.
Good luck to them, but that has no relevance to other Linux distributions or those administering them. Again, this argument of "Red Hat is doing this therefore you have to" holds no water and whenever all else had been exhausted that's what we get. I also wish them luck with the inevitable security problems because they are going to be humdingers even if you had a bunch of maintainers who were extremely responsive to bugs and had a clue what they were doing.
Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.
You have no point at all apart from making a whole load of noise to make it look like you have one.
At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary".
Not an argument I'm afraid, but this is the kind of non sequiturs that systemd critiques usually boil down to once its proponents have exhausted all the nonesense.
Sys admins demand logs they can read under as many circumstances as possible and the ability to take logs off a machine promptly in the event it is compromised. systemd fails conclusively on both counts. The point, and the end.
23.23.142.124
Did a digit go missing? Get flipped? Maybe it meant to say 231.23.142.124
It's redundant in the sense that it's useless. Not redundant in the sense that it's robust.
Did systemd corrupt my logs or not? No idea. Can I get a portion of my logs back, or are they all lost? Nope, they're all lost.
I'm afraid you're really pissing in the wind with the your arguments now.
You mean a disconnect like the fact that you can pretty trivially 100% a couple of servers running feature extracting daemons processing text based logs at the moment for a small cluster of machines?
I have no idea what that load of claptrap means (par for the course with this trail of systemd brain damage), but you obviously don't understand the importance of a push based system. You want to make sure stuff gets pushed as soon as reducing any possibility that logs get altered inbetween. The fact that anyone suggests pulling as a solution means that have no clue at all about system administration.
Where has this absurd notion that text logs are efficient come from?
Fucking hell. The issue here is lowest common denominator. Under as many disastrous circumstances as possible there are those of us who, you know, do fucking administration for a living who have to be able to read log files - and I mean have to. To put a binary logger in the middle of there means there are those of us who can use half a brain cell and work out why that would be a problem. That's the real elephant in the room, but I notice you throw the strawman of efficiency in there.
Of course rsyslog also reads systemd journals natively.
Doesn't help.
In the past to get network logging you needed to install a syslog daemon. And with systemd you still need to install a syslog daemon. What's the big deal?
Have you stopped to think how utterly stupid that statement is? In the past I had syslog running as default. No work necessary. Now I have to run it as a separate daemon from the 'default' logging system just so I can get plain text logs, hoping systemd doesn't corrupt anything inbetween.
If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.
Under no circumstances has systemd been supported on technical grounds (those proposing it keep repeating this ad nauseam in the hope it will just be accepted as fact), nor has there been any extensive discussion in the manner he describes. systemd has been imposed as a de facto default almost overnight and the general consensus has been that it would be accepted with nary a whisper. Now that there is some pushback various characters are getting upset.
Given that this is an extremely core piece of software that a distribution is going to have to support come hell or high water it deserves a huge amount of scrutiny it hasn't got. You've also got to look beyond the code and ask yourself whether it is backed by a group of developers who are very, very, very responsive to security issues and bugs. The answer to that is a big fat NO.
"But desktop environments like Gnome were already requiring systemd before Debian switched to it; Debian cannot hold back the tide."
In every supposedly technical discussion that I have seen about systemd this is the default end argument. That is NOT a technical argument.
Wow, another long post on systemd spouting ideology and rhetoric without nary a valid technical complain....but the project also aims to provide lightweight implementations of what it considers "core" functionality.
What a load of ideological and and rehtorical claptrap.
None of my systemd systems use systemd cron or DHCP for example, even though those daemons exist.
Why do they exist?
WTF?
Debian is not based on Gnome.
I'm afraid it is if you accept systemd and accept the whole list of hard dependencies that haven't existed in the past.
Ahh, yes. Cloud stuff. Where you are processing a lot of data and where your processing and I/O resources are not your own. I always laugh at people who say "Oh, we don't need all that infrastructure stuff" and start moaning "Oh, why does it cost so much and why do we have to spend so much more when we add data?" Not to mention putting your important data on a platform that is financially questionable, has outages that providers simply don't care about and where it's going to be one hell of a PITA to move at any time later owing to the amount of data.
Sounds like a recipe for success.
Yer, it's not the beginning of then end but it is perhaps the end of the beginning.
Office functionality should be helping to sell Microsoft's phone thingies, but they aren't.
Ironically, Poettering's rant only served to highlight the issues and interpersonal problems he was rather than Linus or anyone else.
I'm afraid this is crap no matter how you word it. Verizon themselves attempted to debunk this, and they ended up not doing so. What's more, they've paid. The end.
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.
I can't mod you up any further, but yer, you're spot on. This is actually the default behaviour of a lot of routers. It might look like malice but in this case it could very well be complete laziness and a lack of awareness. Typical ISP in other words.
They could also start using alternative currencies, but I'm assuming they haven't considered that as a risk.
Performance enhancing drugs. Athletes at most levels of competition are at least training on them, so let's be honest, eh?
I'm afraid it's become clear that Lennart has a lot of very serious personal and possibly mental issues that mean he just isn't suited to working with others. The progress of systemd will mean that eventually there will be a serious conflict with the kernel developers, amongst others.
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.
It's exactly the kind of misdirection and smoke-and-mirrors you get from the systemd crew every time a serious shortcoming is brought up. It's a pretty serious mental issue. Oh, and yes, having to deal with a corrupted Windows Event Viewer is exactly like this is going to be. Something you should just not have to deal with.
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.
No, it doesn't. Stop repeating this crap of how I am 'free' to use syslog every time this issue comes up.
It's a Lennart Poettering meltdown and accurately exemplifies the problems people have with him, those around him and why people are justifiably concerned about the software he is being allowed to write. This guy simply has 'issues'.
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.