Except - even if they enforce that with built-in crypto, they won't be able to prevent people sending pre-encrypted data over plaintext / weak crypto media. The only adversely affected will be people with legit interest in encryption.
- attacker is unable to enumerate valid, but locked accounts - attacker is still fully able to access valid, not-locked accounts, obtaining full privileges of these accounts.
seems like Titanic is sinking, but you're still making sure that 3rd class passengers won't try to steal any 1st class passengers' snacks.
I'd be willing to buy the toy. But I'm fairly sure it would require me to sign up to Facebook. Which I definitely refuse, and so, nope, not buying Ocultus Rift.
Had it on my 486 that ran Gentoo, and not just with the kernel but most of apps. By the time Emerge World completed and I'd need to reboot for the upgraded kernel to start up, a new version was already available, and Emerge World ran right after start, on whatever updates happened during the previous run would finish about the time another kernel was available.
Gotta agree. Optimized startup is a nice thing, but not necessary, by far. Definitely not worth sacrificing so much.
(and while startup optimization IS important in embedded, systemd alone is heavyweight enough that it's not really welcome.)
Personally, I'd much rather see a robust, fault-proof hibernation. My Windows desktop has 15 days of uptime by now recorded (since last updates that required reboot) - because thanks to hibernation I can resume work where I ended it last day, everything back to original state, and faster than with cold boot. Linux... if you ever get hibernation to work, after resuming the work several times, programs begin misbehaving. Firefox starts leaking memory left and right, Plasmashell crashes, something everything freezes.
Systemd is really a solution in search of a problem.
it's good at managing dependencies and starting/stopping services on demand (you've got to admit it was a mess before; init.d scripts often not following the standard format) but it could do this without hijacking half of the OS.
I meant centralization of service startup and management (start/stop/reload/reinit). Not centralization of *services*. That's a definitely bad idea.
Init started rc. Rc, besides its own scripts, would branch out into a dozen custom startup sequences for various stuff; xinit, iptables, these are separate initialization systems. It was... manageable, though far from clean.
Systemd trying to *be* everything it can't *start* (and some which it can but still prefers to *be*) is stupid though.
heh. It IS important in Linux for embedded. You switch your Linux toaster on, or whatever you have running Linux, you want it up and toasting in 10 seconds max.
But the approach is totally misguided because Systemd alone adds so much overhead any benefits it might bring are lost on time spent loading Systemd, all its configurations and dependencies. The actual approach is init with custom inittab consisting of 5-6 lines that start only the bare essentials you need. Systemd is the kind of cure that is worse than the disease.
Systemd is a neat idea the same way communism is a neat idea.
Everyone being kind to each other, everyone doing their fair share and receiving their fair share out of honest sense of duty and desire to build a better future for all, no enemies of the system because who'd be stupid to oppose an utopia like that, and nobody slacking off or grabbing more than their fair share because people are inherently honest, generous and laziness doesn't exist.
That's the world where systemd would have been a wonderful solution. Too bad reality doesn't work like that, and Lennart has similar ego problems as Stalin.
So their initial analysis of the problem and consequently the design of their solution falls woefully short of reality...
Yes. Something that looks good on paper. The kind of naivety found in Tom Clancy's novels, where a single clever unorthodox political move brings peace to Middle East.
... and they'll never admit they were wrong in the first place, but will just keep trying to polish that turd into solid gold.
The idea with microkernels is that almost all modules are optional, loosely coupled, and the system loads only what it needs.
Systemd, under guise of modularity, is composed of a set of tightly tied modules which have so many cross-dependencies between each other the whole thing crashes and burns if you remove a single one.
My guess is it's the sunken cost fallacy - in the beginning they didn't realize just how many flaws their idea had, and once they got the thing running initially, they would not admit the failure (ego problem).
That is doable but very cumbersome. You'd need a central makefile for the whole system, and adding or removing anything would require a rebuild.
Gentoo isn't exactly everyone's favorite, and this would make Gentoo's level of problems pale by comparison.
Note it's not just about ordering the startup, it's about fulfilling all the requisites with 'dummy' interfaces until the provider of what the 'dummy' is for starts up, then transparently substituting. "Want to write logs but syslog still didn't start? We provide a queue that will store your logs until syslog... uh, wait, syslog can't do this that way. Welp, fuck syslog, here's our journald, and it has binary log files which are superior because we say so."
I don't quite see how just makefiles could solve that.
OTOH I really don't see the problem with delaying the startup by literally several milliseconds to let syslog start, instead of ripping it off and replacing with something everyone hates. Simply put, some optimizations are definitely not worth the cost.
"Their approaches to any problem they're setting out to solve, real or imagined, are baroque, juvenile, overly complex, brittle, prone to spectacular breakage, and so is their entire everything else."
The problem is moving goalposts.
There is a problem, which they spot, and most people can agree this is a problem.
Then they come up with a solution which is clean, neat, simple and wrong.
Simply, the problem is more complex than what they postulated and their solution, while working on most of it, breaks on the edge cases, which are... more than a bit numerous. And sometimes quite fundamental.
And so, instead of thinking up a different solution, that is more correct, they begin patching the caveats and edge cases in a half-assed manner one by one, building that brittle, baroque, juvenile and overly complex tower on top of the neat core. And as more and more things start falling through the cracks, they keep adding bandaids.
There was a centralized place to perform startup: init. There was no optimization of startup at all. Optimization is arguably desirable, and it makes sense to include it.
There was a zoo of interconnectivity methods that everyone hated, and it broke at a lot of points. A unified interconnectivity hub is desirable. Also, the process of optimization of startup required it. (although it *might* be done as a separate service.)
Management was also a loose recommendation of what boiled down to including start), stop) options in the init scripts, sometimes adhered to, sometimes not really.
There was also the dependency tree, which was non-obvious, easy to break and hard to fix (plus far from unified) - the dependencies were usually embedded in the dependency tree of whatever package distribution system given distro used, and once deployed, finding what requires what usually boiled down to "disable something and see what else breaks." A dependency tree within the startup system is a good thing.
But that's it. Dependency, startup optimization, management (start/stop/reload on demand, bring system to given state/runlevel.) And interconnectivity, which could be delegated to a separate demon. This is a good set for a unix demon should be able to do. All the rest of systemd does is bloat.
Systemd's extra promise was *optimization* of startup.
It was meant to be achieved through creation and binding of sockets: Service X must wait for service Y to start and create a start up, because X needs to bind to a socket Y creates. It won't be using that socket in a while yet, but it can't initialize without that socket present. What systemd does is create that socket so that Service X can bind to it right away, and proceed with startup, and once Y arrives at the point of creation of the socket, it's bound to the socket Systemd created. There, instead of sequence of complete startups of services, which is lengthy, you have only sequence of socket binding, which is fast, and parallel startup, which is fast too.
This is a neat idea which breaks upon meeting the reality.
Because not everything uses sockets. Not everything can start up with the socket merely present, some need it for real right away. Not everything is structured the way systemd envisioned it; some applications aren't just monolithic executables, but e.g. lengthy shell scripts repeating hundreds of calls to a given executable with different parameters (e.g. iptables). They just don't fit that idealized framework.
And so, the framework does what a framework with overinflated ego author does. Including the crap part.
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
Idea: centralized place to optimize startup, management and interconnectivity of all kinds of services.
Problem: some services in their standard form don't quite fit that model.
Solution: let's rewrite them and include as parts of systemd.
The crap part: while the originals were made by experts in that field, the replacements are made by a group of wannabe experts on everything ever, some with overinflated ego. This results in seriously inferior code replacing old 'tried and true' solutions.
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size. If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
Lul what? Lul I'm not touching any dirty hobos to check if they are men or women? Lul 40 years ago someone something, so we need to do something unrelated for someone two generations later? So, you're half-Italian. I'm Polish - so my ethnicity is Slavic. Know where the word "Slave" comes from? Are you going to apologize to me for what your ancestors did to my ancestors about 2000 years ago? Or is 2000 "expired", while 40 is still "valid"?
Let's put "demographics of homeless in USA" and check how "privileged" males are in comparison to females.
It's easy to pick up the top 5% slice, dissect it, and claim any demographics prevalent there is "privileged".
Look at the bottom 5%.
Look at suicide rates. Look at life time expectancy - and causes (work-related usually). Look at incarceration times for the same crime, per gender.
What you're doing is trying to help middle-class minorities to dominate the elites. But when you look at the bottom - at the poorest - you aren't doing SHIT! Because these most oppressed don't fit your narrative - because getting the shortest end of the stick are white men!
Which means Zilow is fully within their rights to sue. Then the blogger presents proofs this falls under safe harbor of fair use, and soundly wins the lawsuit, period.
Zilow can't hope to sue and win. But they can still sue and lose, and that alone is often deterrent enough.
"Defending" is such a nice word until you look at what activities are hidden behind it.
Setting on fire the limo owned by Muhammad Ashraf, a muslim immigrant running a limo rental service. Wounding Luis Villarroel, a mexican immigrant, driver of that limo, with shards of broken windows. All in the name of defending immigrants from Trump.
Look, Soviet Russia was "only defending" other countries from the capitalist oppression too. It's just a narrative.
Honest minorities people behind #notyourshield during gamergate? Read up. First link on Google: "The reality is #notyourshield is an astroturfing campaign designed to invalidate very real accusations of misogyny and racism in gamergate" - a bullshit narrative pushed by SJWs and caught up by liberal press to silence the minorities who don't want their "protection".
Well, probably. If I had to walk on egg shells about what and how I say, I definitely wouldn't want to work at your company. The one I work at - there are no power games, no backstabbing, no snitching, no underhanded tactics, if you screw up you'll get an earful, but if the customer fucked up, you may feel safe the boss won't try to throw you under the bus to retain the business relationship. And if you tell a rude joke, nobody gets offended because we don't hire whiny assholes.
On my first official day rotating on the team, my new manager sent me a string of messages over company chat. He was in an open relationship, he said, and his girlfriend was having an easy time finding new partners but he wasn't. He was trying to stay out of trouble at work, he said, but he couldn't help getting in trouble, because he was looking for women to have sex with. It was clear that he was trying to get me to have sex with him, and it was so clearly out of line that I immediately took screenshots of these chat messages and reported him to HR.
No, simple "not interested" was insufficient.
Uber was a pretty good-sized company at that time, and I had pretty standard expectations of how they would handle situations like this. I expected that I would report him to HR, they would handle the situation appropriately, and then life would go on
In other words: "I expected they would fire him and promote me to his position."
But he was a "stellar performer", bringing a lot of money in, and she was a noob on first day in the team, fresh out of training. So that didn't happen.
And it just couldn't stand. After all, a corporation can't prioritize efficient employees and profit over entitled employees and their peace of mind...
So the shitstorm began, and... now HR will think twice before employing a female engineer.
Slashdot Mirror
Except - even if they enforce that with built-in crypto, they won't be able to prevent people sending pre-encrypted data over plaintext / weak crypto media. The only adversely affected will be people with legit interest in encryption.
So, the effect is:
- attacker is unable to enumerate valid, but locked accounts
- attacker is still fully able to access valid, not-locked accounts, obtaining full privileges of these accounts.
seems like Titanic is sinking, but you're still making sure that 3rd class passengers won't try to steal any 1st class passengers' snacks.
I'd be willing to buy the toy. But I'm fairly sure it would require me to sign up to Facebook. Which I definitely refuse, and so, nope, not buying Ocultus Rift.
Had it on my 486 that ran Gentoo, and not just with the kernel but most of apps. By the time Emerge World completed and I'd need to reboot for the upgraded kernel to start up, a new version was already available, and Emerge World ran right after start, on whatever updates happened during the previous run would finish about the time another kernel was available.
Gotta agree. Optimized startup is a nice thing, but not necessary, by far. Definitely not worth sacrificing so much.
(and while startup optimization IS important in embedded, systemd alone is heavyweight enough that it's not really welcome.)
Personally, I'd much rather see a robust, fault-proof hibernation. My Windows desktop has 15 days of uptime by now recorded (since last updates that required reboot) - because thanks to hibernation I can resume work where I ended it last day, everything back to original state, and faster than with cold boot. Linux... if you ever get hibernation to work, after resuming the work several times, programs begin misbehaving. Firefox starts leaking memory left and right, Plasmashell crashes, something everything freezes.
Systemd is really a solution in search of a problem.
it's good at managing dependencies and starting/stopping services on demand (you've got to admit it was a mess before; init.d scripts often not following the standard format) but it could do this without hijacking half of the OS.
I meant centralization of service startup and management (start/stop/reload/reinit). Not centralization of *services*. That's a definitely bad idea.
Init started rc. Rc, besides its own scripts, would branch out into a dozen custom startup sequences for various stuff; xinit, iptables, these are separate initialization systems. It was... manageable, though far from clean.
Systemd trying to *be* everything it can't *start* (and some which it can but still prefers to *be*) is stupid though.
heh. It IS important in Linux for embedded. You switch your Linux toaster on, or whatever you have running Linux, you want it up and toasting in 10 seconds max.
But the approach is totally misguided because Systemd alone adds so much overhead any benefits it might bring are lost on time spent loading Systemd, all its configurations and dependencies. The actual approach is init with custom inittab consisting of 5-6 lines that start only the bare essentials you need. Systemd is the kind of cure that is worse than the disease.
You're completely missing the point.
Systemd is a neat idea the same way communism is a neat idea.
Everyone being kind to each other, everyone doing their fair share and receiving their fair share out of honest sense of duty and desire to build a better future for all, no enemies of the system because who'd be stupid to oppose an utopia like that, and nobody slacking off or grabbing more than their fair share because people are inherently honest, generous and laziness doesn't exist.
That's the world where systemd would have been a wonderful solution. Too bad reality doesn't work like that, and Lennart has similar ego problems as Stalin.
Yes. Something that looks good on paper. The kind of naivety found in Tom Clancy's novels, where a single clever unorthodox political move brings peace to Middle East.
Ego.
instead of dozen towns to surround with city walls, you have a single continent to secure...
The idea with microkernels is that almost all modules are optional, loosely coupled, and the system loads only what it needs.
Systemd, under guise of modularity, is composed of a set of tightly tied modules which have so many cross-dependencies between each other the whole thing crashes and burns if you remove a single one.
My guess is it's the sunken cost fallacy - in the beginning they didn't realize just how many flaws their idea had, and once they got the thing running initially, they would not admit the failure (ego problem).
That is doable but very cumbersome. You'd need a central makefile for the whole system, and adding or removing anything would require a rebuild.
Gentoo isn't exactly everyone's favorite, and this would make Gentoo's level of problems pale by comparison.
Note it's not just about ordering the startup, it's about fulfilling all the requisites with 'dummy' interfaces until the provider of what the 'dummy' is for starts up, then transparently substituting. "Want to write logs but syslog still didn't start? We provide a queue that will store your logs until syslog... uh, wait, syslog can't do this that way. Welp, fuck syslog, here's our journald, and it has binary log files which are superior because we say so."
I don't quite see how just makefiles could solve that.
OTOH I really don't see the problem with delaying the startup by literally several milliseconds to let syslog start, instead of ripping it off and replacing with something everyone hates. Simply put, some optimizations are definitely not worth the cost.
"Their approaches to any problem they're setting out to solve, real or imagined, are baroque, juvenile, overly complex, brittle, prone to spectacular breakage, and so is their entire everything else."
The problem is moving goalposts.
There is a problem, which they spot, and most people can agree this is a problem.
Then they come up with a solution which is clean, neat, simple and wrong.
Simply, the problem is more complex than what they postulated and their solution, while working on most of it, breaks on the edge cases, which are... more than a bit numerous. And sometimes quite fundamental.
And so, instead of thinking up a different solution, that is more correct, they begin patching the caveats and edge cases in a half-assed manner one by one, building that brittle, baroque, juvenile and overly complex tower on top of the neat core. And as more and more things start falling through the cracks, they keep adding bandaids.
There was a centralized place to perform startup: init. There was no optimization of startup at all. Optimization is arguably desirable, and it makes sense to include it.
There was a zoo of interconnectivity methods that everyone hated, and it broke at a lot of points. A unified interconnectivity hub is desirable. Also, the process of optimization of startup required it. (although it *might* be done as a separate service.)
Management was also a loose recommendation of what boiled down to including start), stop) options in the init scripts, sometimes adhered to, sometimes not really.
There was also the dependency tree, which was non-obvious, easy to break and hard to fix (plus far from unified) - the dependencies were usually embedded in the dependency tree of whatever package distribution system given distro used, and once deployed, finding what requires what usually boiled down to "disable something and see what else breaks." A dependency tree within the startup system is a good thing.
But that's it. Dependency, startup optimization, management (start/stop/reload on demand, bring system to given state/runlevel.) And interconnectivity, which could be delegated to a separate demon. This is a good set for a unix demon should be able to do. All the rest of systemd does is bloat.
Systemd's extra promise was *optimization* of startup.
It was meant to be achieved through creation and binding of sockets: Service X must wait for service Y to start and create a start up, because X needs to bind to a socket Y creates. It won't be using that socket in a while yet, but it can't initialize without that socket present.
What systemd does is create that socket so that Service X can bind to it right away, and proceed with startup, and once Y arrives at the point of creation of the socket, it's bound to the socket Systemd created. There, instead of sequence of complete startups of services, which is lengthy, you have only sequence of socket binding, which is fast, and parallel startup, which is fast too.
This is a neat idea which breaks upon meeting the reality.
Because not everything uses sockets. Not everything can start up with the socket merely present, some need it for real right away. Not everything is structured the way systemd envisioned it; some applications aren't just monolithic executables, but e.g. lengthy shell scripts repeating hundreds of calls to a given executable with different parameters (e.g. iptables). They just don't fit that idealized framework.
And so, the framework does what a framework with overinflated ego author does. Including the crap part.
Because "the crap part" is not what is written on the box. Systemd *appears* attractive. The idea is neat. The promise is tempting.
Including systemd in your distro is like preordering No Man's Sky.
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
Idea: centralized place to optimize startup, management and interconnectivity of all kinds of services.
Problem: some services in their standard form don't quite fit that model.
Solution: let's rewrite them and include as parts of systemd.
The crap part: while the originals were made by experts in that field, the replacements are made by a group of wannabe experts on everything ever, some with overinflated ego. This results in seriously inferior code replacing old 'tried and true' solutions.
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size. If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
Lul what? Lul I'm not touching any dirty hobos to check if they are men or women? Lul 40 years ago someone something, so we need to do something unrelated for someone two generations later? So, you're half-Italian. I'm Polish - so my ethnicity is Slavic. Know where the word "Slave" comes from? Are you going to apologize to me for what your ancestors did to my ancestors about 2000 years ago? Or is 2000 "expired", while 40 is still "valid"?
Let's put "demographics of homeless in USA" and check how "privileged" males are in comparison to females.
It's easy to pick up the top 5% slice, dissect it, and claim any demographics prevalent there is "privileged".
Look at the bottom 5%.
Look at suicide rates. Look at life time expectancy - and causes (work-related usually). Look at incarceration times for the same crime, per gender.
What you're doing is trying to help middle-class minorities to dominate the elites. But when you look at the bottom - at the poorest - you aren't doing SHIT! Because these most oppressed don't fit your narrative - because getting the shortest end of the stick are white men!
Yes, but onus of proof is on the defense.
Which means Zilow is fully within their rights to sue. Then the blogger presents proofs this falls under safe harbor of fair use, and soundly wins the lawsuit, period.
Zilow can't hope to sue and win. But they can still sue and lose, and that alone is often deterrent enough.
"Defending" is such a nice word until you look at what activities are hidden behind it.
Setting on fire the limo owned by Muhammad Ashraf, a muslim immigrant running a limo rental service. Wounding Luis Villarroel, a mexican immigrant, driver of that limo, with shards of broken windows. All in the name of defending immigrants from Trump.
Look, Soviet Russia was "only defending" other countries from the capitalist oppression too. It's just a narrative.
Honest minorities people behind #notyourshield during gamergate? Read up. First link on Google: "The reality is #notyourshield is an astroturfing campaign designed to invalidate very real accusations of misogyny and racism in gamergate" - a bullshit narrative pushed by SJWs and caught up by liberal press to silence the minorities who don't want their "protection".
Well, probably. If I had to walk on egg shells about what and how I say, I definitely wouldn't want to work at your company. The one I work at - there are no power games, no backstabbing, no snitching, no underhanded tactics, if you screw up you'll get an earful, but if the customer fucked up, you may feel safe the boss won't try to throw you under the bus to retain the business relationship. And if you tell a rude joke, nobody gets offended because we don't hire whiny assholes.
No, simple "not interested" was insufficient.
In other words: "I expected they would fire him and promote me to his position."
But he was a "stellar performer", bringing a lot of money in, and she was a noob on first day in the team, fresh out of training. So that didn't happen.
And it just couldn't stand. After all, a corporation can't prioritize efficient employees and profit over entitled employees and their peace of mind...
So the shitstorm began, and... now HR will think twice before employing a female engineer.