And yet here you are, sucking on the teat of a collective endeavour.
Libertarians and other hyper-individualists wander around the supermarket of civilisation, stocked and supplied by other people, filling their pockets, and acting indignant and crying 'robbers!' when security stops them as they try to leave without paying.
management of firewall rules, fstab, networking, process control: all these things are completely insane to be managed exclusively by PID 1.
Sorry, but if you don't understand why a service manager should know about which file systems are mounted and whether or not the network is up before starting services, you have absolutely no authority to talk about these things.
As for process control: that's been a badly implemented part of init since its very beginning, as the ultimate ancestor process on a *nix machine. That systemd in its role as init and cgroup manager allows more fine-grained process control is a good thing.
And firewalling isn't even handled by systemd. The closest thing is the IPAddressAllow directive in unit files, which is a direct re-implementation of tcpwrappers, not firewalling.
Fuck off to your safe space, snowflake. So far it's the rabid anti-systemd folks that keep invading other discussions (like the iproute2 one a while back), all shouting 'it sucks! eleventy!!' without arguments.
Agile is not for the benefit of developers. Agile improves information flow to project managers. It allows for better business decisions.
Nailed it. But I think you miss the main implication: that is and should be the point.
Contrary to what a lot of coders think, code is not an end goal. A working application is not even an end goal. In the end, why we have coders is because we need to automate (business) processes. And without better information flow to the business, the code produced will not do that satisfactorily.
Generally speaking, I'd say the one benefit agile tends to bring is that it officially discourages developers from hunkering down into a huge project and simply "going dark" for a year, at least if done correct. Those types of going dark periods often don't end well. I've always thought that was common sense anyhow, but it's probably better for leads and producers to be able get a bit more visibility into those sorts of projects.
That's because most programmers and most managers seem to think in terms of 'product': "We want this application, and we need it done by X". Instead, programming should be about data flow: what information flows into a process, and what information does the organisation want out of that input?
I've seen developers up close, and sometimes their singular devotion to "i want to improve my application/my code" at the expense of "what does the end customer need" really needs to be managed.
A close engagement with the end user, and incremental development can help fine tune a better vision on the data flow and necessary transformation, but if no-one from the management team on down focuses on the reason we have developers in the first place, you get a dysfunctional organisation, where management does not trust the devs and uses 'Agile' to micromanage them, and devs start treating their slices of code as their private fiefdoms instead of watching the big picture.
So, badly implemented agile is a problem, as is badly implemented just about any process.
If a process or methodology is that sensitive to implementation errors, I'd say it is broken, at the very least in the sense that it is trying to solve the wrong problem. It is at worst a sign of the the Techie Problem: trying to find a tech (in this case process) solution to a socai problem.
You know why systemd is winning? It's because all real opposition is from mental midgets who do things like confuse iproute2, a ten year old suite of tools, with Potterings work.
And frankly, I think these are people you even loop up to.
Too bad it's the old tool that doesn't deal with corner cases. Just one example: multiple IPs on one interface. ifconfig can't handle that at all, except by creating aliases. On modern deployments, especially with virtualisation, that happens to be not even a corner case, but essential functionality.
So, tell me, oh great Unix wizard, how do I unlink(2) a socket? Why do I have to call socket(2) and bind(2), and then listen to it or connect to a remote socket before I can even think of calling read(2) or write(2)?
'Everything is a file' is a convenient shorthand, not a truth graven in stone.
Slashdot Mirror
What I get is that you are too stupid to recognise a metaphor.
And you're a libertarian.
But I repeat myself.
And yet here you are, sucking on the teat of a collective endeavour.
Libertarians and other hyper-individualists wander around the supermarket of civilisation, stocked and supplied by other people, filling their pockets, and acting indignant and crying 'robbers!' when security stops them as they try to leave without paying.
You mean those glory days when programming was considered a menial job and farmed out to the typist pool (all ladies, of course)?
No, I'm a sysadmin who has to deploy the shit some coders deliver and deal with the unhappy users. But thank you for playing, shithead.
Sorry, but if you don't understand why a service manager should know about which file systems are mounted and whether or not the network is up before starting services, you have absolutely no authority to talk about these things.
As for process control: that's been a badly implemented part of init since its very beginning, as the ultimate ancestor process on a *nix machine. That systemd in its role as init and cgroup manager allows more fine-grained process control is a good thing.
And firewalling isn't even handled by systemd. The closest thing is the IPAddressAllow directive in unit files, which is a direct re-implementation of tcpwrappers, not firewalling.
Fuck off to your safe space, snowflake. So far it's the rabid anti-systemd folks that keep invading other discussions (like the iproute2 one a while back), all shouting 'it sucks! eleventy!!' without arguments.
One anecdote, versus just about all distribution maintainers. I know how I believe.
Nailed it. But I think you miss the main implication: that is and should be the point.
Contrary to what a lot of coders think, code is not an end goal. A working application is not even an end goal. In the end, why we have coders is because we need to automate (business) processes. And without better information flow to the business, the code produced will not do that satisfactorily.
That's because most programmers and most managers seem to think in terms of 'product': "We want this application, and we need it done by X". Instead, programming should be about data flow: what information flows into a process, and what information does the organisation want out of that input?
I've seen developers up close, and sometimes their singular devotion to "i want to improve my application/my code" at the expense of "what does the end customer need" really needs to be managed.
A close engagement with the end user, and incremental development can help fine tune a better vision on the data flow and necessary transformation, but if no-one from the management team on down focuses on the reason we have developers in the first place, you get a dysfunctional organisation, where management does not trust the devs and uses 'Agile' to micromanage them, and devs start treating their slices of code as their private fiefdoms instead of watching the big picture.
If a process or methodology is that sensitive to implementation errors, I'd say it is broken, at the very least in the sense that it is trying to solve the wrong problem. It is at worst a sign of the the Techie Problem: trying to find a tech (in this case process) solution to a socai problem.
Smart people would conclude that that might mean that systemd is actually solving essential problems.
Yeah, those nasty regulators, stopping me and Vito from protecting our local shopkeepers against damage to their businesses.
Oh look, another mental midget who can't even read.
Iproute2's age has got nothing to do with breaking existing convention with new tools
(Emphasis mine)
Wow. Wrong within one sentence. You really are an idiot.
Ouch. I couldn't find it's exact age, but I knew it was already widespread 10 years ago, so I originally settled for that in this discussion.
You know why systemd is winning? It's because all real opposition is from mental midgets who do things like confuse iproute2, a ten year old suite of tools, with Potterings work.
And frankly, I think these are people you even loop up to.
Like I said, convenient shorthand. You know it, and I know it, but the guy I was replying to obviously doesn't.
Go back to your parents' basement and leave the sysadminning to the professionals:
Do you have any idea how old iproute2 is? Idiot.
Too bad it's the old tool that doesn't deal with corner cases. Just one example: multiple IPs on one interface. ifconfig can't handle that at all, except by creating aliases. On modern deployments, especially with virtualisation, that happens to be not even a corner case, but essential functionality.
So, tell me, oh great Unix wizard, how do I unlink(2) a socket? Why do I have to call socket(2) and bind(2), and then listen to it or connect to a remote socket before I can even think of calling read(2) or write(2)?
'Everything is a file' is a convenient shorthand, not a truth graven in stone.
If only that were true, we would be spared your ignorance.
Here's a hint: it has something to do with why BSD was used to try out technologies for DARPA.
How about you prove it?
You must be new here. Slashdot has always posted more than pure tech stuff. And there have always been short-sighted idiots whining about it.
He did no such thing, but thank you for showing your colours with that barely disguised "he's a moooslim!!!1!" dog whistle.