But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do...
Where fully manual means it drops you to a shell and you manually assemble the RAID. In other words, WONTFIX
So go have someone give you a hug and calm down in your safe space while you desperately try to find some odd interpretation that fits your worldview, but don't bother to reply unless you lead with a big fat apology.
Meanwhile, I'll go on enjoying the availability benefits of a systemd free machine.
What of the seller's good faith. Shouldn't the seller be making a good faith effort to make the terms of the sale clear rather than hiding key points in the fine print? Shoul;dn't good faith dictate that the seller actually has the legal right to make the sale (e.g. actually owns what he is selling)?
What you describe is a predator-prey relationship. Is that what you really think should be the basis of civilization?
There was discussion of it being in udevd, but guess what udevd is a part of these days? And, of course it was never a problem before because the other init systems would issue the command to start the RAID (or mount btrfs) as an imperative rather than in response to an event (central to the design of systemd) and so let the specialized code that actually knows if the array can be assembled under existing conditions make the go/no-go decision.
And that is why the distros were able to work around it by using scripting in intiramfs to assemble the RAIDs before letting systemd bumble it and in the case of btrfs I was able to get the desired behavior by dumping systemd for SysV (so the mount command would be issued as an imperative). It's not an implementation bug, it's a design flaw.
>p>So, no lie, just you desperately not wanting your precious to be tarnished. Had you been more interested in understanding than in yelling lie at the first opportunity, you might have understood the problem sooner.
Just stuff that into the event handler and let it be responsible for it. That's the beauty of such a modular system, it's versatile. The new parts can come in early, late, or not at all depending on need. There can even be more than one so they can specialize in subsystems or special cases.
I am not in principle opposed to a replacement init so long as it plays well with others, but I would need a compelling reason to do it that couldn't be otherwise accomplished
Sorry, no. I put up a reference and a google search you could use. If you don't want to believe it, fine. But if you want to call people a liar, you'd better have a better reason than "I can't read so I don't acknowledge your evidence."
Sorry about goring your sacred cow and that you have so much butthurt over it. I suggest you retreat to your safe space and seek counselling.
And you apparently can't read. I posted a representative message from the systemd list (not a particular distro) where LP himself admitted to not having a solution (you did actually read it, didn't you).
I did indicate that a number of distros solved the immediate problem for RAID by doing an end run around systemd.
You didn't even read well enough to understand that I was testing with BTRFS. I solved the problem (that is, configured the system correctly) by disabling systemd and putting SysV back in charge of booting. Suddenly it all worked.
Summary, your favorite shiny got dissed and now you're all butthurt and lashing out impotently. You'll no doubt be whining about micro-aggressions next.
Actually, no. What you'll do is get the compiler and processor that are super fast for a tiny fraction of your code and slow as a log truck going up hill the rest of the time instead of the cpu/compiler that is twice as fast for 100% of your code. You will lose big on that deal.
Servers sitting in a light's out facility rarely have things plugged ind unplugged.
The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.
The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.
This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.
Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.
So you learned to do the easiest part and called good. 'grats. Now, consider my use case. I build a btrfs using RAID1 in a VM. I dettached one of the virtual drives to test things and rebooted the VM. Systemd dumped me to an emergency shell with the network down. Try as I might, even digging through the 100 or more low level config files kept under the rug I could see no way to show systemd the error of it's ways. And yes, I specified mount option degraded on the kernel command line and fstab, but systemd ignored it. All it knew is that it was prepared to wait forever for that no longer connected disk to come online and was not going to be made to see reason.
Naturally, I hit up google. Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX. It never did get fixed as far as I can tell. The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.
THAT is why I object to systemd. It's just too damned easy to find something is simply won't do as soon as you use a system in any manner that LP doesn't. I guess he doesn't do much with servers.
Now, if they would just keep their fingers out of all the pies I wouldn't care. You can use systemd and I'll stick to scripts. Alas, they insist on sticking their fingers in every pie through a pernicious knot of dependencies. For a while it seemed that the stronger the objections, the more things became dependent on it. That's why it took Devuan so long to purge it from Jessie.
Not for a long time now. Get closer and you find that the carrot is made of wax. But there's no reason we can't have a more balanced system with proper health care and a basic income. That and restore the progressiveness of taxation.
Interestingly, the 3.5 jack does a double duty. On many phones, the headphone leads are also the FM radio antenna. It *IS* a standard connector. Anything you add is not (at least not today).
Is it really worthwhile to burn the 2 spare conductors now and forever as a headphone connection? It sounds like churn for the sake of churn from here.
You haven't looked nearly deep enough. For one, in spite of having the best players in the game, the all-star game is filled with lackluster gameplay. It is understood to be more spectacle than sport. The Yankees often have the same problem. They pay top dollar to attract great players, you'd think they would be serious contenders for the World Series each and every year. They're not. The difference between a really good pitcher and a great pitcher often comes down to working well with a catcher to frame a ball as a strike.
As for the steal, even an attempted steal can rattle the pitcher. That doesn't make a 'sacrifice steal' a good idea, but it does color the decision to attempt it or at least look like you might be ready to attempt it. The latter is a good way to draw a balk or an error on the throw.
Sabermetrics says the steal is never worth the attempt. Many teams have manufactured many runs from the steal in fact. Others seem better at attempting it than at succeeding.
Likewise, a pitcher's win/loss record is not necessarily a good measure of his quality.
In theory, sabermetrics could become a powerful tool but in fact there are far too many variables it doesn't account for and so it remains necessary to take it with a few grains of salt.
Slashdot Mirror
Let's see, from that thread, we have from LP:
But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do...
Where fully manual means it drops you to a shell and you manually assemble the RAID. In other words, WONTFIX
So go have someone give you a hug and calm down in your safe space while you desperately try to find some odd interpretation that fits your worldview, but don't bother to reply unless you lead with a big fat apology.
Meanwhile, I'll go on enjoying the availability benefits of a systemd free machine.
Yes but worse. The Columbia price of $0.01 for 10 was a huge red flag. The AdoreMe prices are not that obviously too good to be true.
Columbia at least gave you something for the additional charges. (Apparently AdoreMe gives store credit now, but didn't at first).
What of the seller's good faith. Shouldn't the seller be making a good faith effort to make the terms of the sale clear rather than hiding key points in the fine print? Shoul;dn't good faith dictate that the seller actually has the legal right to make the sale (e.g. actually owns what he is selling)?
What you describe is a predator-prey relationship. Is that what you really think should be the basis of civilization?
Nor do they support any practical way to put a stop to them.
And that is exactly why the government doesn't have a financial incentive to tell you only good news.
WOW, you really read that into it?
There was discussion of it being in udevd, but guess what udevd is a part of these days? And, of course it was never a problem before because the other init systems would issue the command to start the RAID (or mount btrfs) as an imperative rather than in response to an event (central to the design of systemd) and so let the specialized code that actually knows if the array can be assembled under existing conditions make the go/no-go decision.
And that is why the distros were able to work around it by using scripting in intiramfs to assemble the RAIDs before letting systemd bumble it and in the case of btrfs I was able to get the desired behavior by dumping systemd for SysV (so the mount command would be issued as an imperative). It's not an implementation bug, it's a design flaw.
>p>So, no lie, just you desperately not wanting your precious to be tarnished. Had you been more interested in understanding than in yelling lie at the first opportunity, you might have understood the problem sooner.
Just stuff that into the event handler and let it be responsible for it. That's the beauty of such a modular system, it's versatile. The new parts can come in early, late, or not at all depending on need. There can even be more than one so they can specialize in subsystems or special cases.
I am not in principle opposed to a replacement init so long as it plays well with others, but I would need a compelling reason to do it that couldn't be otherwise accomplished
No, they worked around it because the systemd team were running around in circles with their pants around their ankles.
Sorry, no. I put up a reference and a google search you could use. If you don't want to believe it, fine. But if you want to call people a liar, you'd better have a better reason than "I can't read so I don't acknowledge your evidence."
Sorry about goring your sacred cow and that you have so much butthurt over it. I suggest you retreat to your safe space and seek counselling.
And you apparently can't read. I posted a representative message from the systemd list (not a particular distro) where LP himself admitted to not having a solution (you did actually read it, didn't you).
I did indicate that a number of distros solved the immediate problem for RAID by doing an end run around systemd.
You didn't even read well enough to understand that I was testing with BTRFS. I solved the problem (that is, configured the system correctly) by disabling systemd and putting SysV back in charge of booting. Suddenly it all worked.
Summary, your favorite shiny got dissed and now you're all butthurt and lashing out impotently. You'll no doubt be whining about micro-aggressions next.
Actually, no. What you'll do is get the compiler and processor that are super fast for a tiny fraction of your code and slow as a log truck going up hill the rest of the time instead of the cpu/compiler that is twice as fast for 100% of your code. You will lose big on that deal.
Did you even read the summary? You know, the one about the group building and maintaining a systemd free distro who just released a beta?
Servers sitting in a light's out facility rarely have things plugged ind unplugged.
The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.
Poof, no controversy, no objections.
If you're going to call someone a liar, you need to back it up. So back it up or STFU.
Do the google, you'll find the same problem reported a year later. I pointed to that one because it best described the problem.
You know systemd was supposed to run in the initramfs, right?
Since scripts made it easy and systemd made it hard, I'd say scripts win. I have enough to do without handicapping myself.
Here's one of a few discussions
Also google on: systemd degraded btrfs
The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.
This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.
Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.
Funny you post that it isn't going anywhere in an article about a significant milestone accomplished.
So you learned to do the easiest part and called good. 'grats. Now, consider my use case. I build a btrfs using RAID1 in a VM. I dettached one of the virtual drives to test things and rebooted the VM. Systemd dumped me to an emergency shell with the network down. Try as I might, even digging through the 100 or more low level config files kept under the rug I could see no way to show systemd the error of it's ways. And yes, I specified mount option degraded on the kernel command line and fstab, but systemd ignored it. All it knew is that it was prepared to wait forever for that no longer connected disk to come online and was not going to be made to see reason.
Naturally, I hit up google. Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX. It never did get fixed as far as I can tell. The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.
THAT is why I object to systemd. It's just too damned easy to find something is simply won't do as soon as you use a system in any manner that LP doesn't. I guess he doesn't do much with servers.
Now, if they would just keep their fingers out of all the pies I wouldn't care. You can use systemd and I'll stick to scripts. Alas, they insist on sticking their fingers in every pie through a pernicious knot of dependencies. For a while it seemed that the stronger the objections, the more things became dependent on it. That's why it took Devuan so long to purge it from Jessie.
Very ugly.
You mean other than that if you are stepping on someone else's signal, they are stepping on yours as well.
But IT'S SO FLUFFY!!!!!
Not for a long time now. Get closer and you find that the carrot is made of wax. But there's no reason we can't have a more balanced system with proper health care and a basic income. That and restore the progressiveness of taxation.
Interestingly, the 3.5 jack does a double duty. On many phones, the headphone leads are also the FM radio antenna. It *IS* a standard connector. Anything you add is not (at least not today).
Is it really worthwhile to burn the 2 spare conductors now and forever as a headphone connection? It sounds like churn for the sake of churn from here.
You haven't looked nearly deep enough. For one, in spite of having the best players in the game, the all-star game is filled with lackluster gameplay. It is understood to be more spectacle than sport. The Yankees often have the same problem. They pay top dollar to attract great players, you'd think they would be serious contenders for the World Series each and every year. They're not. The difference between a really good pitcher and a great pitcher often comes down to working well with a catcher to frame a ball as a strike.
As for the steal, even an attempted steal can rattle the pitcher. That doesn't make a 'sacrifice steal' a good idea, but it does color the decision to attempt it or at least look like you might be ready to attempt it. The latter is a good way to draw a balk or an error on the throw.
Sabermetrics says the steal is never worth the attempt. Many teams have manufactured many runs from the steal in fact. Others seem better at attempting it than at succeeding.
Likewise, a pitcher's win/loss record is not necessarily a good measure of his quality.
In theory, sabermetrics could become a powerful tool but in fact there are far too many variables it doesn't account for and so it remains necessary to take it with a few grains of salt.
So make it illegal to provide or make it.
You're a pedophole aren't you? SHAZAM! all your rights are gone! Now shut up while we dismantle your house nail by nail looking for whatever.