... we're still alive!

[_jr_]

Tools always fail when they are trying to be smart. (At least until they develop actual mind reading capabilities.)

 

[Plume]

I don't know what people are doing.
My configuration file is (excluding comments) just "flat-volumes = no" and I never had any problem of any kind.

 

[rSl]

imho, mr. poettering wanted his code (pulseaudio,systemd,etc.) to be too smart, with too much functionality built in, so these verry central components are failing too often.
when these new components were introduced, i really couldn't understand why redhat pushed them so agressively into gnome etc. (i was a fedora/gnome user about that time)
for me the beauty of gnu/linux is about modularity, do one thing at a time and do it right. maybe he should do an os of his own.

 

[rygD]

Why do his own when he can just force his stuff on the existing Linux community?

As for everything else you said, it seems that way to me, and I think those are the reasons so many of us have a problem with how things have happened. But we are just being whiny children (or that it's how it seems we get treated, although I say the man that is fucking everything up is the one acting like a child).

I was warning someone that teaches Red Hat classes about all the problems of systemd, based on both my experience and the comments of others. She, and others, acted like I was overreacting to what was essentially a nonissue. I eventually took the RHEL 7 version of the classes, and the instructor of some of my classes repeatedly said that he didn't like the new ways of doing some things (he also admitted that some of the systemd stuff seemed better, that he needed to finish learning everything himself, and that part of why he didn't like it was it was unfamiliar to him, so it rendered a lot of his experience and knowledge useless*). When I was talking to the other instructor I knew our conversation drifted to the topic of Linux and her current classes. While she didn't exactly admit I was right, she did seem to think it changed too much, and was problematic for those that already had experience, or for those learning how to use systemd that might eventually encounter systems without it. We didn't discuss my security concerns, and that is her interest in a lot of things, so I should ask what her thoughts are with that.


*This throwing away of knowledge and experience became my biggest concern when I took the new classes, even before I started the third one. I felt like even the common things I used to do without really thinking about them no longer working was a bit ridiculous. Maybe I am just pessimistic.

 

[Djoga'Ro]

To me it looks alot like fashism - not talking about NS. They know how the world shoult be and force their way onto it, and you're either with them or can go fuck yourself.

 

[rSl]

yes, systemd somehow felt 'too different' for me. while i embrace new technology and ideas, i also like to stick to older stuff that's working 'just right'.
maybe i'm conservative here, but invalidating things that are working fine, is just like reinventing the wheel every two months (tm).
on the other side, change is a good thing imho. sticking too long with something that does not fit in anymore, is not really helping too.
a good change needs to adress an issue and bring some new value. with systemd i can just not really see the value of it. initscripts are plain text and understandable (ok one
could remove a ton of cruft from them , but this whole symlinking in /etc/systemd really looks not like a great improvement to me.
no text-logfiles? c'mon!
basically it replaces nearly all gnu lowlevel commands with xxxctl commands, so it allready is an os inside an os somehow.
but i will try it out again with jessie, currently i'm still using wheezy. i think from a technical standpoint it should work ok by now, but i really didn't like
the style how red hat forced this onto the users and the philosopy of this 'one software to rule them all' aproach.
independend from this, i learned that the nsa uses red hat linux as their main os for xkeyscore (the software that makes all the bulkdata they steai easy accessable to the analysts) and probably on a lot more of their big iron,
that explained these huge earnings red hat had year for year verry good to me. so i switched to arch linux and then to debian using my rpi, as a training for the pyra os.

ps. down with selinux, too!

 

[rygD]

ps. down with selinux, too!

For me personally, I can't agree there. I think it is extremely valuable. I do get where you are coming from, and people should be cautious. For me skipping it wouldn't be advantageous, and I think it is a great tool for companies and many other organizations, possibly including schools. The one group I am not sure if it should be used by is probably the largest, or at least the most significant as it pertains to this discussion, as it relates to Pyra and other personal computers: typical (Linux) users. For them I just recommend looking into it and deciding if they trust the US Government/NSA enough to use it on their private, personal systems.

 

[rSl]

For me personally, I can't agree there. I think it is extremely valuable. I do get where you are coming from, and people should be cautious. For me skipping it wouldn't be advantageous, and I think it is a great tool for companies and many other organizations, possibly including schools. The one group I am not sure if it should be used by is probably the largest, or at least the most significant as it pertains to this discussion, as it relates to Pyra and other personal computers: typical (Linux) users. For them I just recommend looking into it and deciding if they trust the US Government/NSA enough to use it on their private, personal systems.

ok point taken. sadly nsa's mission is 'collect it all' and not 'secure it all', so i'm a little bit cautios with this 'feature'.

 

[rygD]

There was a time when they "wouldn't" collect on US citizens. That may not reassure those in other countries, however it doesn't matter now anyway, since everyone is a potential enemy/threat.

 

[rSl]

There was a time when they "wouldn't" collect on US citizens. That may not reassure those in other countries, however it doesn't matter now anyway, since everyone is a potential enemy/threat.

when a government thinks that all people are bad, it's really time to change the government. just don't try to own the world and treat the people with respect might do the trick.
but hey, it's about linux and fun here! there are soo many good and happy packages in this pyra debian os, we can really have a lot of fun with, right!

 

[logenkain]

I just never understood the sudden jump to systemd when there were already alternatives available. runit for example, is pretty happy to deal with.

 

[Silent-Hunter]

I will never understand what's wrong with OpenRC.

 

[bzar]

Debian people had long conversations on systemd, so did Arch. Perhaps those conversations can sate your curiosity. Then there's the conspiracy theories (meant literally, not as a pejorative) about strong-arming tactics being in play.

All in all, I think the people to ask are the distribution maintainers and application developers that embraced systemd.

 

[Swordfish II]

when a government thinks that all people are bad, it's really time to change the government. just don't try to own the world and treat the people with respect might do the trick.
but hey, it's about linux and fun here! there are soo many good and happy packages in this pyra debian os, we can really have a lot of fun with, right!

This is why when I retire I will leave the U.S. to live in a nice second world country. You know a cheap kind of tropical place with healthcare facilities that may not be cutting edge, but they can still take care of the basics.

Maybe a nice 40ft sailboat with auto winches, a little kicker for pulling into a berth, and solar battery rack + small generator. I have the nautical science background and experience to sail anywhere

 

[Grench]

I found Pulse audio to be easier to work with once I came to the realization that it works more or less like a professional sound mixing board that has had half of it's capabilities removed.

You have a series of inputs. A 4 piece band on a stage can have 17+ inputs into the board between multi-mic'd drums, instruments and vocals.

You have a series of outputs. There are the main speakers facing the audience, but anymore each person on stage will have in-ear monitors and/or a dedicated floor monitor pointed at their head.

All of the inputs need to be weighted against each other to create a coherent collective sound coming out of the main speakers.

All of the inputs need to be weighted differently against each other for every on-stage and in-ear monitor depending on the musician's preferences to what they want &/or need to hear.

With pulse audio, what it's missing is actually -more- control over specific mixing inputs to specific outputs - and good integration to allow more control over the inputs being mixed into the 'master'.

In theory, the master volume (technically master amplification in this case), should be set once for the circumstances then left alone. At that point, all of the input sources can be amplified or attenuated before the final (master) amplification step. We should be turning the volume up/down based on the currently foreground application, not the system master volume.

What is missing? Well, the source mix result is singular - all of the inputs feed one stream that is then output to speakers, headphones what not at varying volume, but the mix in the middle is constant.

To work as a mixing board, the mix needs to be specific to the output. Effectively meaning that you could have bass boosted on a music player but not messaging bleeps and turn down the bleeps for the headphones while having the bass turned down so it doesn't distort and the bleeps turned up for the base speakers while having the hdmi audio tuned to movie output with only audio from VLC going to it and no bleeps allowed. All this should be controlled simultaneously with independent controls for every source on every output.

That requires more than 6 sliders and a single pair of volume up/down buttons though.

 

[ible]

as long as american people are afraid of other people hurting them (in big and scary ways), the privacy issues will continue. not as many people are willing to die for freedom it seems.

my plan is to build a machine, an artificial intelligence, which spies on you, every moment of every day.

the backup plan is retireland, maybe make a private golf course to play on. walk around a beautiful countryside, you know, the important things.

 

[Djoga'Ro]

my plan is to build a machine, an artificial intelligence, which spies on you, every moment of every day.

I know, mine already told me about it.

 

[Wrath Of Khan]

I know, mine already told me about it.

This is actually a good fil- the trailer makes it look naff- though its surely dated a little.

 

[Black Sliver]

for me the beauty of gnu/linux is about modularity, do one thing at a time and do it right.

That's why it is/should be called systemd/linux -- maybe sometime it will be systemd/uboot with boot-to-systemd ... wait ... why stop there? why not integrate a bootloader into systemd?

Debian people had long conversations on systemd, so did Arch

Afaik (one of the) main reason(s) for this is to unify init "scripts", so a vendor can ship them (instead of the maintainer). The fact that systemd does more than that is the main reason why people hate it.
I have my doubts that systemd is the right choice for OSes targeting more than just desktop:
a) dbus - makes sense on a desktop pc, but not on server or embedded,
b) "permission management" (logind, etc.) makes only sense on desktop, imho. Linux' permission system (groups) works nicely for other use-cases.
c) reduced freedom/increased bloat (you can't just use/take/mix the parts you need/want),
d) not suitable for *all* devices (e.g. IoT, WRT, ...),
e) last but not least: despite the fact that performance should be better (multi-core C vs. single-core bash), it wasn't for a single device for me.
*BUT* since Pyra should be a ready-to-use end-user desktop-like device, systemd may/does make sense for pyra's default OS.

I found Pulse audio to be easier to work with once I came to the realization that it works more or less like a professional sound mixing board that has had half of it's capabilities removed.

It's just not good/ready/bug-free enough. I used it since "day one" when Ubuntu forced it on us. It was really bad back then - but often still better than plain alsa or oss.
Anyway, after that I still had my share of problems with it. Being on Arch (rolling, latest pulse), I can say that it's still full of bugs, at least when mixing sound cards or using network streaming. The main difference to professional sound is the magical buffering system. It will increase buffer size on the go, which introduces delays, which leads to Problem 1: mixing different sound cards may (or will?) increase the buffer to unlimitted sizes (e.g. +1 second delay per minute). I fixed this by using PortAudio against ALSA and just "replaying" a sink to a source and Problem 2: when streaming over network, the delay will randomly increase (bad connection?) but the logic to decrease the buffer size seems to be missing. I found no settings whatsoever to fix this. You have to go through ALSA, manage the buffering youself and hope that PA does not insert a magic buffer (TM) between your ALSA stream and your ALSA (hardware) sink.
Anyway, for most use cases pulse is better than ALSA. The idea is good, but it has too many bugs and limitations. Routing *everything* through userspace and mixing *everything* in software (no hardware acceleration) using self-growing buffers defies the idea of a good, low-delay sound card.

 

[Djoga'Ro]

Just call systemd what is/brings - middleware.