If you think that is why I prefer not to be locked in to systemd and pa, you have been singing through the whole discussion, but as I said, your business, though I ask that you not waste people's time by asking questions when you won't listen to the answer.
Flat is desirable because it makes it easy to appropriately color your current choice in music with the eq.
It's important to define audiophile. Some like quality equipment that produces superior results when used properly. Others (audio weenies)spend thousands on cables that don't work any better than a typical consumer cable and then 'break them in' for some reason, buy magic crystals to hook on the connectors and pay $50 to have their room conditioned over the phone.
I have no idea where you got the idea that pulseaudio is considered best of breed. Mostly it's considered something you're better off removing if you can. I say that as an actual professional who gave it every opportunity to work.
Just to add to the pain, 10 years later the documentation is still a crying shame. That's fine for some things, but for system software you want everyone to use, it will not do.
He was a co-developer on Avahi and was implementing an already defined API. For the most part though, Avahi just handles the hostname resolution which is a small project. It may (or may not) be capable of more but I have never seen anything more used in practice.
Systemd more closely resembles pulseaudio in scope. I doubt there would be many complaints about pulseaudio if it was only used for the system beep.
System init is much too important to risk on that track record without some really good evidence of a strong design. The hairball dependency tree suggests this is heading in the pulseaudio direction, not the avahi direction.
That would be closer to the right thing, though the hooks should be optional. If they aren't, then we get stuck with a poorly designed API.
I find it hard to imagine why Gnome even benefits from a systemd hook. What use could it possibly be? Sure, an app that is an optional part of gnome (or better, 'sold separately') might be useful, but the consequences of running Gnome without systemd should be at most that that one app doesn't run and the rest works as it always has.
It's like your car not starting because you hung a different air freshener from the rear view. (We had to have a car analogy in here somewhere:-)
Most people who care at all about audio kill off PA. ALSA handles it much better by itself. I killed off PA when I got tired of having all video I watched look like the dubbed martial arts movies where the lips and the audio have nothing to do with each other.
You might be surprised to learn that many people don't install PA at all and things work just fine.
I see. So you would never smear a surgeon by deciding that you will not be operated on by someone who kills 80% of his patients even though the surgery should have less than 1% mortality?
You believe people should be promoted even if all of their work so far has had to be redone?
You would happily have your car re-painted by a guy whose car has overspray on all of the glass and trim?
You see no reason not to go to the restaurant that gave you food poisoning the last two times you went there?
What a strangely dysfunctional world you must live in!
It doesn't seem like that is it. He plugs in headphones, volume goes away. He sets volume to something reasonable. That reasonable settinmg SHOULD then be considered the last master volume setting he had when the headphones were plugged in, but apparently that doesn't happen.
Why? The beauty of using scripts is that the scripts can invoke a helper and that helper can use cgroups. I don't need for init itself to be changed in any way. I can do it myself without getting anyone else involved and without wading through anyone else's code. Then I can try it out on just one or two daemons on my own system. Once done, others can add it to their init scripts of not as they see fit.
Unless someone screws up the cgroups API really badly, that is.
A friend and I were idly speculating one day shortly after the announcement from P&F that started the whole cold fusion thing. What if it was locally hot? What if something in the crystalline structure of the metal electrodes created extreme conditions on very small scale, permitting fusion that appeared to be 'cold'.
I'm not claiming anyone has ever gotten that to happen or that anyone ever will, but it is a vaguely plausible mechanism that doesn't do any rewriting of physics.
It's not like we don't know of a few ways to make fusion happen, it's just that they don't break even so far.
It looks a little more complex from the brief search I did. They are also concerned with monitoring the started daemon through cgroups. Currently, that's not TOO hard, but we have been warned that the API may be changing.
I have no idea how old you are, but look back. How similar are you to yourself 20 years ago? Are there things you did in your high school years that you would never do now? Perhaps things that would cause you to blow a gasket if your kids did them now?
Would you care to have potential employers make assumptions about your work ethic based on how you kept 'forgetting' to clean your room when you were six?
If you declare bankruptcy you carry a black mark for seven years. Perhaps arrests and convictions should also go away in seven years. Certainly they should in 20 years.
Keeping daemons alive is easily enough added. Just have OpenRC start a program whose job is to re-run the daemon when necessary. It could be the same manager I proposed for SysV, in fact.
Slashdot Mirror
If you think that is why I prefer not to be locked in to systemd and pa, you have been singing through the whole discussion, but as I said, your business, though I ask that you not waste people's time by asking questions when you won't listen to the answer.
They used to. Now they just make it 'loud' unless the musicians have enough clout to insist otherwise.
Flat is desirable because it makes it easy to appropriately color your current choice in music with the eq.
It's important to define audiophile. Some like quality equipment that produces superior results when used properly. Others (audio weenies)spend thousands on cables that don't work any better than a typical consumer cable and then 'break them in' for some reason, buy magic crystals to hook on the connectors and pay $50 to have their room conditioned over the phone.
Skippy, you're doing that owl thing again.
I have no idea where you got the idea that pulseaudio is considered best of breed. Mostly it's considered something you're better off removing if you can. I say that as an actual professional who gave it every opportunity to work.
Just to add to the pain, 10 years later the documentation is still a crying shame. That's fine for some things, but for system software you want everyone to use, it will not do.
I had no idea the Daleks had gone into the computer business.
That explains a lot actually...
If you want to plug your ears and sing La La La, it's your business really. Hope it works out for you.
He was a co-developer on Avahi and was implementing an already defined API. For the most part though, Avahi just handles the hostname resolution which is a small project. It may (or may not) be capable of more but I have never seen anything more used in practice.
Systemd more closely resembles pulseaudio in scope. I doubt there would be many complaints about pulseaudio if it was only used for the system beep.
System init is much too important to risk on that track record without some really good evidence of a strong design. The hairball dependency tree suggests this is heading in the pulseaudio direction, not the avahi direction.
That would be closer to the right thing, though the hooks should be optional. If they aren't, then we get stuck with a poorly designed API.
I find it hard to imagine why Gnome even benefits from a systemd hook. What use could it possibly be? Sure, an app that is an optional part of gnome (or better, 'sold separately') might be useful, but the consequences of running Gnome without systemd should be at most that that one app doesn't run and the rest works as it always has.
It's like your car not starting because you hung a different air freshener from the rear view. (We had to have a car analogy in here somewhere :-)
Most people who care at all about audio kill off PA. ALSA handles it much better by itself. I killed off PA when I got tired of having all video I watched look like the dubbed martial arts movies where the lips and the audio have nothing to do with each other.
You might be surprised to learn that many people don't install PA at all and things work just fine.
I see. So you would never smear a surgeon by deciding that you will not be operated on by someone who kills 80% of his patients even though the surgery should have less than 1% mortality?
You believe people should be promoted even if all of their work so far has had to be redone?
You would happily have your car re-painted by a guy whose car has overspray on all of the glass and trim?
You see no reason not to go to the restaurant that gave you food poisoning the last two times you went there?
What a strangely dysfunctional world you must live in!
It doesn't seem like that is it. He plugs in headphones, volume goes away. He sets volume to something reasonable. That reasonable settinmg SHOULD then be considered the last master volume setting he had when the headphones were plugged in, but apparently that doesn't happen.
Is it really smearing when you look at how someone's last major project went when judging how well their current project is likely to work?
Why? The beauty of using scripts is that the scripts can invoke a helper and that helper can use cgroups. I don't need for init itself to be changed in any way. I can do it myself without getting anyone else involved and without wading through anyone else's code. Then I can try it out on just one or two daemons on my own system. Once done, others can add it to their init scripts of not as they see fit.
Unless someone screws up the cgroups API really badly, that is.
That's because one of their team is the one monkeying with the API. Just saying
Look at the link you posted. Read the subtitle.
A friend and I were idly speculating one day shortly after the announcement from P&F that started the whole cold fusion thing. What if it was locally hot? What if something in the crystalline structure of the metal electrodes created extreme conditions on very small scale, permitting fusion that appeared to be 'cold'.
I'm not claiming anyone has ever gotten that to happen or that anyone ever will, but it is a vaguely plausible mechanism that doesn't do any rewriting of physics.
It's not like we don't know of a few ways to make fusion happen, it's just that they don't break even so far.
Problem is, it's not the deadwood that leaves.
Nobody has ever been eaten by a picture or a bear...
It would seem you answered your own question.
It looks a little more complex from the brief search I did. They are also concerned with monitoring the started daemon through cgroups. Currently, that's not TOO hard, but we have been warned that the API may be changing.
I have no idea how old you are, but look back. How similar are you to yourself 20 years ago? Are there things you did in your high school years that you would never do now? Perhaps things that would cause you to blow a gasket if your kids did them now?
Would you care to have potential employers make assumptions about your work ethic based on how you kept 'forgetting' to clean your room when you were six?
If you declare bankruptcy you carry a black mark for seven years. Perhaps arrests and convictions should also go away in seven years. Certainly they should in 20 years.
Keeping daemons alive is easily enough added. Just have OpenRC start a program whose job is to re-run the daemon when necessary. It could be the same manager I proposed for SysV, in fact.
Why would a developer maintain a unit file suitable only for Linux when they also support *BSD which can never go to systemd?
The problem isn't that the Gimp developers took any steps to depend on systemd, that tendril is creeping up on them from underneath.