Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The Politics of systemd
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 6:02 pm    Post subject: Reply with quote

Anon-E-moose wrote:
genstorm wrote:
Anon-E-moose wrote:
So it's not really clear "when emerging" WTF is really going on.

There's even a news item now so there's not really an excuse to not understand the issue.


A/o this morning when I synced, I haven't seen a "news item" referencing upower.


It only displays when you have it installed.

Anon-E-moose wrote:
And as I said the non-arch version still wants to pull in systemd.
Which means running an ~amd64 pkg, for which you've given people grief before.


There is nothing wrong with that; at least to me, an ~amd64 user.

It is just the case here that the old branch needs systemd, whereas the new branch doesn't; the old branch is well supported by reverse dependencies, the new branch reverse dependencies still need to migrate to.
Back to top
View user's profile Send private message
mrbassie
Apprentice
Apprentice


Joined: 31 May 2013
Posts: 220

PostPosted: Thu Jun 05, 2014 6:03 pm    Post subject: Reply with quote

thanks again, I'll try both.
Why is this sort of thing happening though and why is it being tolerated nay encouraged? If Thompson and Ritchie are Engels and Marx and Stallman is Lenin and Poettering is Stalin I just hope Torvalds doesn't end up like Trotsky.


Last edited by mrbassie on Thu Jun 05, 2014 6:06 pm; edited 2 times in total
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 6:04 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Who else is to blame for laziness, if not the non-RH DE's.


That was more a reference to upower / systemd; as in the second statement, it was written as blaming themselves instead of us blaming them, I don't see a reason for them to blame themselves. Maybe later, but it's too early to see that; when what is happening in the past months has a negative effect to those DEs, ...

mrbassie wrote:
Why is this sort of thing happening though and why is it being tolerated nay encouraged?


Because if pm-utils slows down development, it slows down development; if UPower needs fixed from pm-utils and it doesn't get those, it'll pick an alternative or drop it; etc... As a consequence, this happenings propagate to distributions, which then propagates to users; both have to tolerate this, and try to do as much possible to limit the consequences. Beyond that, it boils down to encouragement that goes in the opposite direction; someone somewhere needs to step up to take on the work again, it is only that that can turn this whole happening upside down to correct the equation.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2323
Location: Dallas area

PostPosted: Thu Jun 05, 2014 6:23 pm    Post subject: Reply with quote

TomWij wrote:
Anon-E-moose wrote:
genstorm wrote:
Anon-E-moose wrote:
So it's not really clear "when emerging" WTF is really going on.

There's even a news item now so there's not really an excuse to not understand the issue.


A/o this morning when I synced, I haven't seen a "news item" referencing upower.


It only displays when you have it installed.


I assume you mean when "upower" is installed.

Quote:
Anon-E-moose wrote:
And as I said the non-arch version still wants to pull in systemd.
Which means running an ~amd64 pkg, for which you've given people grief before.


There is nothing wrong with that; at least to me, an ~amd64 user.

It is just the case here that the old branch needs systemd, whereas the new branch doesn't; the old branch is well supported by reverse dependencies, the new branch reverse dependencies still need to migrate to.


It doesn't bother me to run ~amd64, I have a few pkgs that are that way, though I go back to non-~amd64 when it becomes stable enough.

I just found it ironic that on the one hand people get given grief for running ~amd64 (and the troubles that sometimes go with it)
and on the other hand thinking that people should automatically move to ~amd64.
It sends out a mixed message, IMO.

Anyway glad it's getting sorted out.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2500
Location: The Peanut Gallery

PostPosted: Thu Jun 05, 2014 6:42 pm    Post subject: Reply with quote

warrens wrote:
Say that sysvinit still works with hardware a decade from now, do you think that the upstream projects that we use will still write the init scripts for sysvinit? I don't think that they will. From what I have heard, writing systemd units is easier to do than sysvinit scripts. If that is so, I can see upstream developers writing systemd units and tell the users that run sysvinit to write there own sysvinit scripts. When that happens sysvinit will be dead.

You're confusing sysvinit with sysv-rc (as previously used on debian, and elsewhere.) sysvinit is configured with /etc/inittab, and doesn't do very much at all, besides reaping zombie pids, respawning tty's and switching run-levels.

sysvinit is very useful, imo; and just hands over to whatever you want, usually openrc in Gentoo. It's better to have a simple pid 1, afaic.

Writing openrc initscripts is very easy, ime; runscript provides a very nice setup, so initscripts are a bit like ebuilds, with most of the work done elsewhere, and you only add what you need to. It's perfectly possible to write purely declaratively, but equally you can control whatever you want. (cf: man runscript)

That doesn't mean we should write awful shell; that leads to scripts that are brittle, slow and full of holes, and sometimes a presumption that it's shell's fault.

No one does that with sucky C, perl, python or C++ code: we blame the coder, and either throw it away, patch it or use another impl. We don't blame the language.

Every language has its idioms, and it's perfectly possible to write awful code in any language. openrc is a progression on sysv-rc, based on a completely different worldview than systemd. For me it's far more in line with the rest of *nix and POSIX.

For a start we still have the ability to pick and choose components, which is pretty important if you're building your own distro. I've been told on so many occasions Gentoo gives us the tools to build our own distro, so I'm going to pick the ones which don't close down my options in areas that have nothing to do with them. This is not about some hypothetical notion of choice: ime modularity leads to better software, which is why Unix has prospered and blossomed into the tools used to build the latest One True Way de-jour.

I don't ofc care what anyone else wants to use: why would I? I find all the evangelising, and agenda-driven "gentle" pushes most peculiar.

Good luck all.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 7:29 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I just found it ironic that on the one hand people get given grief for running ~amd64 (and the troubles that sometimes go with it)
and on the other hand thinking that people should automatically move to ~amd64.
It sends out a mixed message, IMO.


That is for people that mix amd64 and ~amd64, as that is an untested situation; running either amd64 or ~amd64 alone isn't a problem, and needs no griefs.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum