It's getting slightly tiring watching morons pull out their apt-cache and grep magic in order to try and search for plain strings of 'systemd' and deny the obvious dependency chain going on here every time a systemd topic comes up:
Besides, for anyone who has the vaguest idea of how systemd actually works, or tries to work, then you would know that playing dependency tennis doesn't work. systemd works through the house of cards IPC system that is DBus so dependencies are now exceptionally well hidden amongst a fucking forest of namespaces.
You are wrong about offshore wind. It does not fluctuate in the same way as wind over land. Also the term 'unreliable' is completely wrong. Wind is reliable. For that you have a weather/windforecast, that is updated every 15 mins and is used to adapt the plant and the grid for the next few hours.
I'm afraid you're missing the elephant in the room here, or more likely painting over it. No matter how you rebalance the grid you still have a bunch of exceptionally expensive-to-maintain wind turbines out of service for a period of time. When anything is out of action it is expensive and no amount of grid rebalancing paints over that. It is simply inefficient.
Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?
I prefer t o run unnecessary things like sound as daemons in userspace. Thank you very much.
Because that's exactly where it should be. No other kernel interface says to an application "Sorry, this interface is in use. one at a time please". Stupid, but initially the whole whole rationale behind PulseAudio according to Poettering was to make mixing work and no software mixing code would be accepted in the kernel, which is odd, because no one had ever tried. The 'one interface at a time' thing would have been reason enough for Linus to consider the issue. No other kernel interface does it, and for good reason.
Well he does, but just not quite enough right now to cause a massive fuss. He has already stated that the kdbus patches that the systemd people think will fly under the radar will have to be tested in distribution kernels first.
Newsflash: systemd is popular among people with the technical background to be in charge of choosing a daemon and interface manager.
Newsflash, none of the passive aggressive people behind systemd have the technical background to be building such a system and you only need to look at the kernel developers' opinion on that one. It's not like ill-advised software hasn't been pushed before and then hastily retracted in the open source world.
I think that's possibly the best advertisement for Ruby here, along with all the other derogatory comments about Ruby posted by some guy called 'Anonymous Coward'. He's really busy.
PSA: Code clarity doesn't have anything to do with making a compiler that outputs slow binaries.
It actually does once you realise the implications of creating a higher level language in the quest for said code clarity and more to the point, developer productivity. That's a trend that should be pretty obvious to anyone who feels qualified to comment on this topic.
LOL, try again. We are talking about server-side JavaScript here!
The worst possible use. JavaScript used for sever software is a perfect example of idiotic web programmers meddling in things they shouldn't be going anywhere near.
Of course it does. RedHat leads on a lot of products that are upsteam for many of the distributions, in particular Debian. Suse also supports this shift with their products. So yes it is relevant.
PaaS concerns have no relevance to the vast majority of system administrators out there. We require an init system amongst other things that work and where things can be pieced together when things do go wrong. 'Process management' is not a reason for a poorly defined piece of software such as systemd attempting to replace long used and very well tested pieces of software in areas where it has no business being
Do you really believe that RedHat doesn't know what they are doing?
No.
Do you really find that plausible?
Yes. The maintainers of systemd have demonstrated consistently how unresponsive they are in this and other projects.
No, it wasn't, but then that's the kind of argument we've come to expect isn't it? 'Yes it was'. There is no technically valid reason to start replacing large and well tested parts of an OS in order to get 'event based processing of service management', which doesn't even mean anything.
Check out he prices for EC2 reserved instances, if you know you'll need that server for 3 years.
If I was committing myself to a server for three years then I'd buy one where all the resources were guaranteed to be mine...... The whole point of the 'cloud' is to get yourself away from long-term commitments, move around your infrastructure and upgrade as necessary. The fact that Amazon, and others, have started doing this to look better against dedicated hardware tells me that things are not sustainable in that castle up in the sky.
Prices are similar per core to buying entry-level Dell rackmount servers with 3-year support contracts. Of course, the physical Dell has more memory and disk than the VM with the same core count, so you come out ahead there if you needs lots of memory, or local disk, but not by a lot.
I don't think comparing and equating dedicated hardware to a transient Amazon instance in a data centre you will never see is a terribly good idea. The whole point of the cloud is to remove yourself from such long-term commitments. I also have a chuckle at any salesperson who starts using doublespeak like telling me how less expensive something is 'per core' or 'per watt'. It's usually a whole load of nonsensical corner cases they've dreamed up.
Once again, missing the point. In my (small) shop, by using azure (which has worked well for us), we avoid having to use money to hire admins to maintain any sort of in house servers we might have.
Who maintains your Azure infrastructure (I hope you built in all that lovely redundancy for these problems) and how often do you really need to maintain internal servers? If these are on 24x7 you're going to be paying through the nose and if you miss a monthly fee, off you go. Not to mention that cloud servers are horrifically under resourced compared to hardware you can buy, so you generally need many more of them, and none of the bandwidth, I/O or CPU resources are guaranteed to be yours no matter what your meaningless agreement says.
We can then put that money towards more developers (or better salaries for us current devs), as well as paying for training, nicer dev machines, etc.
Ahhh, yes. Developers who believe deployment can be bypassed as a cost and running applications in production (which is kind of important to any company running web applications and who relies on them for income) simply doesn't matter.
At the same time, if we do have a problem with any sort of hosted service through azure, support is literally a phone call away, and I can't remember the last time a resolution didn't happen within a couple hours.
You've been exceptionally lucky, or you're being economical with the truth;-).
Sure, cloud computing has its short-comings. But it has also allowed a litany of small companies who simply can't afford to own their own infrastructure to do business.
I've also seen a litany of small companies go out of business with cashflow issues who thought like that. Funny that. Yes, the infrastructure is cheaper if you don't run it all the time. I think I once calculated that if you have a server on for more than eight hours a day then you're simply being milked for a monthly fee.
Explosive machine gun rounds from the cannon would cause larger holes, not smaller ones.
No they wouldn't, because it depends on where they explode, if at all and there were entry and exits. Keep digging though. This simple shrapnel assumption is rather curious given what has been found: http://www.anderweltonline.com.... The cockpit area was certainly hit by something very, very different than shrapnel.
Nope. These were clearly defined as clean holes, in one end out the other. Shrapnel is much more haphazard.
Because cannon fire has a minimum size of the puncture it can make, the size of the shell. The resulting marks on the aircraft will be a circle of that size, given a nice face-on strike, or elongations if the angle was more glancing. It can get much larger if the metal tears.
Now look at the image. There are many, many holes in the aircraft that are much smaller than a cannon shell. In fact, there are quite a few that are exactly the size of a piece of shrapnel.
Look at what image? I didn't quote one and you certainly haven't either even though you refer to one, although there are suspiciously not as many to look at thes edays. Claptrap.
So that's why "west no one seems to want to even entertain" the idea, it's clearly false.
No, our western governments are not immune to propaganda themselves, as much as that may shock you. But feel free to stop questioning, your government has your best interests at heart and keep sucking in whatever you watch on Fox, or CNN or whatever. Keep hold of the comfort blanket.
What we do know is that the plane was downed with multiple, small, high velocity projectiles. The wreckage was found with them. In the west no one seems to want to even entertain the possibility that this was cannon fire. On the other hand, if it was downed by Ukraine then this hardly helps Russia's case.
Too many smoke and mirrors on this, and sadly, I don't think we will ever get the truth.
No. Systemd supporters give plenty of technical reasons for their support. In my case (for one thing) it is wanting event based processing of service management. Systemd offers that, sysV rc doesn't. Like it or not, that's a technical reason.
I don't. I'm a sys admin and I don't believe that adding that required a completely new init system that has now morphed into something altogether very, very different that I will have to pick up the pieces on. Sorry, not a valid technical argument but then these things get very tricky for people because they can't actually pin down what systemd is supposed to do.
On the other hand, you anti guys keep bringing up things like this shit, or 'not Unix philosophy'...
I don't know if you brain cells have noticed, but Linux was built by Linus from the kernel on up with a Unix philosophy in mind that has served it very, very well in the server world and the functions it performs. After many decades of that philosophy and the lessons learned from it you would think people would have learned what does and doesn't work, but apparently not.
'monolithic hairball'. Those are not technical arguments.
Given that it's an extremely core piece of software then I'm afraid people are justifiably concerned about a monolithic piece of software with poorly defined goals and requirements that they'll have to end up supporting when its maintainers tell us all a security issue isn't their problem to fix. Sorry, but that very much is a technical argument, as well as one of maintainership. systemd fails on both counts.
Do me a favour, and refrain from answering until you can actually muster a technical argument against systemd.
I find that extremely funny coming from some moron who puts 'Unix philosophy' in quotes and nonchalantly dismisses decades worth of hard, hard lessons learned and quite obviously hasn't the faintest idea about working with a Linux system. But then, that's what we've come to expect isn't it?
I agree. Systemd is now about a "2nd kernel" or "userspace plumbing". Essentially a redesign of Linux.
The problem is I don't know what there is for Debian to debate. They don't have the upsteam influence.
The problem is that they have to support it, because the evidence tells us that when the inevitable security problems come calling the 'upstream maintainers' won't be terribly responsive.
Cue some example of seeing a half flushed log line in a file, as though someone actually got any information from that line.
When a binary logging system fails you lose a hell of a lot more than a line's worth of logs. Or are you just going to keep making yourself look like the idiot you are?
It's becoming rapidly apparent to me that the people who complain no one listens to their complaints about systemd haven't realized they don't listen or attempt to learn about what they're complaining about.
Blah, blah, blah, I will spout crap and try and muddy the waters.
Slashdot Mirror
It's getting slightly tiring watching morons pull out their apt-cache and grep magic in order to try and search for plain strings of 'systemd' and deny the obvious dependency chain going on here every time a systemd topic comes up:
http://packages.ubuntu.com/viv...
libudev:
http://packages.ubuntu.com/viv...
Source: systemd
Besides, for anyone who has the vaguest idea of how systemd actually works, or tries to work, then you would know that playing dependency tennis doesn't work. systemd works through the house of cards IPC system that is DBus so dependencies are now exceptionally well hidden amongst a fucking forest of namespaces.
You are wrong about offshore wind. It does not fluctuate in the same way as wind over land. Also the term 'unreliable' is completely wrong. Wind is reliable. For that you have a weather/windforecast, that is updated every 15 mins and is used to adapt the plant and the grid for the next few hours.
I'm afraid you're missing the elephant in the room here, or more likely painting over it. No matter how you rebalance the grid you still have a bunch of exceptionally expensive-to-maintain wind turbines out of service for a period of time. When anything is out of action it is expensive and no amount of grid rebalancing paints over that. It is simply inefficient.
Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ? I prefer t o run unnecessary things like sound as daemons in userspace. Thank you very much.
Because that's exactly where it should be. No other kernel interface says to an application "Sorry, this interface is in use. one at a time please". Stupid, but initially the whole whole rationale behind PulseAudio according to Poettering was to make mixing work and no software mixing code would be accepted in the kernel, which is odd, because no one had ever tried. The 'one interface at a time' thing would have been reason enough for Linus to consider the issue. No other kernel interface does it, and for good reason.
Well he does, but just not quite enough right now to cause a massive fuss. He has already stated that the kdbus patches that the systemd people think will fly under the radar will have to be tested in distribution kernels first.
Newsflash: systemd is popular among people with the technical background to be in charge of choosing a daemon and interface manager.
Newsflash, none of the passive aggressive people behind systemd have the technical background to be building such a system and you only need to look at the kernel developers' opinion on that one. It's not like ill-advised software hasn't been pushed before and then hastily retracted in the open source world.
I simply cannot afford this shit. I need to administer unattended systems.
and if the text logs are corrupted (or silently deleted) and assuming your computer can boot properly, how easy is it to read them?
An awful lot easier to get and put back together than binary logs. They will get corrupted under a lot more circumstances.
They've open sourced a lot of stuff that they're having trouble getting anyone to use.
I think that's possibly the best advertisement for Ruby here, along with all the other derogatory comments about Ruby posted by some guy called 'Anonymous Coward'. He's really busy.
PSA: Code clarity doesn't have anything to do with making a compiler that outputs slow binaries.
It actually does once you realise the implications of creating a higher level language in the quest for said code clarity and more to the point, developer productivity. That's a trend that should be pretty obvious to anyone who feels qualified to comment on this topic.
LOL, try again. We are talking about server-side JavaScript here!
The worst possible use. JavaScript used for sever software is a perfect example of idiotic web programmers meddling in things they shouldn't be going anywhere near.
No normal person wants to deal with smug, "opinionated", Zed Shaw-inspired hipsters who swear all the time...
It's funny that those are exactly the people who Zed Shaw railed against.
Of course it does. RedHat leads on a lot of products that are upsteam for many of the distributions, in particular Debian. Suse also supports this shift with their products. So yes it is relevant.
PaaS concerns have no relevance to the vast majority of system administrators out there. We require an init system amongst other things that work and where things can be pieced together when things do go wrong. 'Process management' is not a reason for a poorly defined piece of software such as systemd attempting to replace long used and very well tested pieces of software in areas where it has no business being
Do you really believe that RedHat doesn't know what they are doing?
No.
Do you really find that plausible?
Yes. The maintainers of systemd have demonstrated consistently how unresponsive they are in this and other projects.
RedHat is going to be all over security issues.
Past history of the maintainers says otherwise.
No, it wasn't, but then that's the kind of argument we've come to expect isn't it? 'Yes it was'. There is no technically valid reason to start replacing large and well tested parts of an OS in order to get 'event based processing of service management', which doesn't even mean anything.
Check out he prices for EC2 reserved instances, if you know you'll need that server for 3 years.
If I was committing myself to a server for three years then I'd buy one where all the resources were guaranteed to be mine...... The whole point of the 'cloud' is to get yourself away from long-term commitments, move around your infrastructure and upgrade as necessary. The fact that Amazon, and others, have started doing this to look better against dedicated hardware tells me that things are not sustainable in that castle up in the sky.
Prices are similar per core to buying entry-level Dell rackmount servers with 3-year support contracts. Of course, the physical Dell has more memory and disk than the VM with the same core count, so you come out ahead there if you needs lots of memory, or local disk, but not by a lot.
I don't think comparing and equating dedicated hardware to a transient Amazon instance in a data centre you will never see is a terribly good idea. The whole point of the cloud is to remove yourself from such long-term commitments. I also have a chuckle at any salesperson who starts using doublespeak like telling me how less expensive something is 'per core' or 'per watt'. It's usually a whole load of nonsensical corner cases they've dreamed up.
As opposed to a western sympathetic president who is also a Nazi?
Ahhhh, a westerner's view of knowledge of world politics and history...........
Once again, missing the point. In my (small) shop, by using azure (which has worked well for us), we avoid having to use money to hire admins to maintain any sort of in house servers we might have.
Who maintains your Azure infrastructure (I hope you built in all that lovely redundancy for these problems) and how often do you really need to maintain internal servers? If these are on 24x7 you're going to be paying through the nose and if you miss a monthly fee, off you go. Not to mention that cloud servers are horrifically under resourced compared to hardware you can buy, so you generally need many more of them, and none of the bandwidth, I/O or CPU resources are guaranteed to be yours no matter what your meaningless agreement says.
We can then put that money towards more developers (or better salaries for us current devs), as well as paying for training, nicer dev machines, etc.
Ahhh, yes. Developers who believe deployment can be bypassed as a cost and running applications in production (which is kind of important to any company running web applications and who relies on them for income) simply doesn't matter.
At the same time, if we do have a problem with any sort of hosted service through azure, support is literally a phone call away, and I can't remember the last time a resolution didn't happen within a couple hours.
You've been exceptionally lucky, or you're being economical with the truth ;-).
Sure, cloud computing has its short-comings. But it has also allowed a litany of small companies who simply can't afford to own their own infrastructure to do business.
I've also seen a litany of small companies go out of business with cashflow issues who thought like that. Funny that. Yes, the infrastructure is cheaper if you don't run it all the time. I think I once calculated that if you have a server on for more than eight hours a day then you're simply being milked for a monthly fee.
Explosive machine gun rounds from the cannon would cause larger holes, not smaller ones.
No they wouldn't, because it depends on where they explode, if at all and there were entry and exits. Keep digging though. This simple shrapnel assumption is rather curious given what has been found: http://www.anderweltonline.com.... The cockpit area was certainly hit by something very, very different than shrapnel.
The pictures of wreckage we've seen show the latter, not the former.
Nope, they don't. However, good luck getting pictures of evidence of cannon fire: http://www.anderweltonline.com...
Just as important, we know the rebels were operating air-to-air batteries in the area...
No, we don't. Hearsay from CNN etc. doesn't count here.
Yes, it's called "shrapnel".
Nope. These were clearly defined as clean holes, in one end out the other. Shrapnel is much more haphazard.
Because cannon fire has a minimum size of the puncture it can make, the size of the shell. The resulting marks on the aircraft will be a circle of that size, given a nice face-on strike, or elongations if the angle was more glancing. It can get much larger if the metal tears.
Now look at the image. There are many, many holes in the aircraft that are much smaller than a cannon shell. In fact, there are quite a few that are exactly the size of a piece of shrapnel.
Look at what image? I didn't quote one and you certainly haven't either even though you refer to one, although there are suspiciously not as many to look at thes edays. Claptrap.
http://www.anderweltonline.com...
So that's why "west no one seems to want to even entertain" the idea, it's clearly false.
No, our western governments are not immune to propaganda themselves, as much as that may shock you. But feel free to stop questioning, your government has your best interests at heart and keep sucking in whatever you watch on Fox, or CNN or whatever. Keep hold of the comfort blanket.
What we do know is that the plane was downed with multiple, small, high velocity projectiles. The wreckage was found with them. In the west no one seems to want to even entertain the possibility that this was cannon fire. On the other hand, if it was downed by Ukraine then this hardly helps Russia's case.
Too many smoke and mirrors on this, and sadly, I don't think we will ever get the truth.
No. Systemd supporters give plenty of technical reasons for their support. In my case (for one thing) it is wanting event based processing of service management. Systemd offers that, sysV rc doesn't. Like it or not, that's a technical reason.
I don't. I'm a sys admin and I don't believe that adding that required a completely new init system that has now morphed into something altogether very, very different that I will have to pick up the pieces on. Sorry, not a valid technical argument but then these things get very tricky for people because they can't actually pin down what systemd is supposed to do.
On the other hand, you anti guys keep bringing up things like this shit, or 'not Unix philosophy'...
I don't know if you brain cells have noticed, but Linux was built by Linus from the kernel on up with a Unix philosophy in mind that has served it very, very well in the server world and the functions it performs. After many decades of that philosophy and the lessons learned from it you would think people would have learned what does and doesn't work, but apparently not.
'monolithic hairball'. Those are not technical arguments.
Given that it's an extremely core piece of software then I'm afraid people are justifiably concerned about a monolithic piece of software with poorly defined goals and requirements that they'll have to end up supporting when its maintainers tell us all a security issue isn't their problem to fix. Sorry, but that very much is a technical argument, as well as one of maintainership. systemd fails on both counts.
Do me a favour, and refrain from answering until you can actually muster a technical argument against systemd.
I find that extremely funny coming from some moron who puts 'Unix philosophy' in quotes and nonchalantly dismisses decades worth of hard, hard lessons learned and quite obviously hasn't the faintest idea about working with a Linux system. But then, that's what we've come to expect isn't it?
I agree. Systemd is now about a "2nd kernel" or "userspace plumbing". Essentially a redesign of Linux.
The problem is I don't know what there is for Debian to debate. They don't have the upsteam influence.
The problem is that they have to support it, because the evidence tells us that when the inevitable security problems come calling the 'upstream maintainers' won't be terribly responsive.
Cue some example of seeing a half flushed log line in a file, as though someone actually got any information from that line.
When a binary logging system fails you lose a hell of a lot more than a line's worth of logs. Or are you just going to keep making yourself look like the idiot you are?
It's becoming rapidly apparent to me that the people who complain no one listens to their complaints about systemd haven't realized they don't listen or attempt to learn about what they're complaining about.
Blah, blah, blah, I will spout crap and try and muddy the waters.