Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
udev is doomed
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 1:57 am    Post subject: Reply with quote

Tony0945 wrote:
I chose eudev instead of mdev purely because it's in the tree.


mdev is in tree.
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7939
Location: Somewhere over Atlanta, Georgia

PostPosted: Mon Mar 03, 2014 2:25 am    Post subject: Reply with quote

Yes, but it's hiding. ;)

@Tony0945. mdev is part of busybox.

- John
_________________
I can confirm that I have received between 0 and 999 National Security Letters.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Mon Mar 03, 2014 3:52 am    Post subject: Reply with quote

Anon-E-moose wrote:
Tom, I looked at your last post to see what you were saying.

The bug was about systemd, and this discussion was about udev. Two different things.


systemd is an udev provider, as it is listed in virtual/udev; that is thus an example that I came up with, as that affected my system. ssuominen has given another example for the split udev; which is another udev provider, but applies to systemd as well because it is a part thereof. Though, the udev problems were hidden from sight due to the security bug taking precedence.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2689

PostPosted: Mon Mar 03, 2014 1:06 pm    Post subject: Reply with quote

I'm still running stock udev and not running systemd.

Am I asking for trouble some time in the next year or so by doing this, and should I be switching to either eudev or mdev?

Or would I be asking for trouble by switching to eudev because it's future maintenance is not guaranteed?

I'm a little fearful pf mdev because from what I understand it's missing some function like automount, which I don't need, but my wife does.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 1:12 pm    Post subject: Reply with quote

depontius wrote:
I'm still running stock udev and not running systemd.

Am I asking for trouble some time in the next year or so by doing this, and should I be switching to either eudev or mdev?

Or would I be asking for trouble by switching to eudev because it's future maintenance is not guaranteed?

I'm a little fearful pf mdev because from what I understand it's missing some function like automount, which I don't need, but my wife does.


This is the funny part of the whole situation. People get worked up over nothing and switch to $whatever.

As a maintainer of sys-fs/udev, I can assure you, it is not going anywhere nor it will ever require systemd. The whole purpose of the package
is to provide the original udev for the use of any init system, like sys-apps/openrc.
As in, nothing has changed. Nor will.

I'm just stating this as a fact. I don't mind if you or anyone else wants to experiment with eudev. That's perfectly okay with me. The useful
patches will for sure flow from eudev to udev upstream, so any work done by the eudev guys, is still appericiated.
I'm stating this, because there are people who are trying to twist this situation out of technical facts into some religious discussion.
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4200
Location: Removed by Neddy

PostPosted: Mon Mar 03, 2014 1:29 pm    Post subject: Reply with quote

ssuominen wrote:
depontius wrote:
I'm still running stock udev and not running systemd.

Am I asking for trouble some time in the next year or so by doing this, and should I be switching to either eudev or mdev?

Or would I be asking for trouble by switching to eudev because it's future maintenance is not guaranteed?

I'm a little fearful pf mdev because from what I understand it's missing some function like automount, which I don't need, but my wife does.


This is the funny part of the whole situation. People get worked up over nothing and switch to $whatever.

As a maintainer of sys-fs/udev, I can assure you, it is not going anywhere nor it will ever require systemd. The whole purpose of the package
is to provide the original udev for the use of any init system, like sys-apps/openrc.
As in, nothing has changed. Nor will.

I'm just stating this as a fact. I don't mind if you or anyone else wants to experiment with eudev. That's perfectly okay with me. The useful
patches will for sure flow from eudev to udev upstream, so any work done by the eudev guys, is still appericiated.
I'm stating this, because there are people who are trying to twist this situation out of technical facts into some religious discussion.

But you can't blame people ... On one hand Pottering is quoted in saying
Quote:

Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely


Yet also stating something along the lines that udev will always be able to build individually since it is needed for some liveCD's or something

SO on one hand it is stated he want non-sysd udev dead BUT on the other stating it will always build separate. Now the overall functionality of non-sysd udev is the big unknown... REALLY big unknown.
Sure not a problem for today, not a problem for tomorrow ... but *maybe* one in the future.

Now I am using udev and eudev (trying eudev on desktop just cause of shinies, no real preference) so its a moot point right now. But since it has been shown there is a big uncertainty surrounding non-sysd edev is it really unexpected to have some vocal complains from some?
Whether an init system should pull in udev is anothing thing, just like swallowing networking and logging (where does init end? at the wordprocessor....?) thats a different sysd discussion

As a platform to progress development its great rather than having a stagnant "it works (for a certain definition)" HOW that is being forced is another discussion.
Honestly the best solution is the community fully embraces systemd & the state of udev. That way these perceived bad decisions/directions can be better discussed by a committee of all rather than 3 (iir its actually only 3 people that commit to sysd)
_________________
A free press is the unsleeping guardian of every other right that free men prize; it is the most dangerous foe of tyranny. Where men have the habit of liberty, the Press will continue to be the vigilant guardian of the rights of the ordinary citizen.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2689

PostPosted: Mon Mar 03, 2014 1:32 pm    Post subject: Reply with quote

ssuominen wrote:

As a maintainer of sys-fs/udev, I can assure you, it is not going anywhere nor it will ever require systemd. The whole purpose of the package
is to provide the original udev for the use of any init system, like sys-apps/openrc.
As in, nothing has changed. Nor will.


Thank you. That's good enough for me.

In general I run a stable system, though I do like to run ~arch kernels. I also run piecemeal ~arch where it's required for some package or other that I specifically desire, but not in general.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 1:37 pm    Post subject: Reply with quote

Naib wrote:
ssuominen wrote:
depontius wrote:
I'm still running stock udev and not running systemd.

Am I asking for trouble some time in the next year or so by doing this, and should I be switching to either eudev or mdev?

Or would I be asking for trouble by switching to eudev because it's future maintenance is not guaranteed?

I'm a little fearful pf mdev because from what I understand it's missing some function like automount, which I don't need, but my wife does.


This is the funny part of the whole situation. People get worked up over nothing and switch to $whatever.

As a maintainer of sys-fs/udev, I can assure you, it is not going anywhere nor it will ever require systemd. The whole purpose of the package
is to provide the original udev for the use of any init system, like sys-apps/openrc.
As in, nothing has changed. Nor will.

I'm just stating this as a fact. I don't mind if you or anyone else wants to experiment with eudev. That's perfectly okay with me. The useful
patches will for sure flow from eudev to udev upstream, so any work done by the eudev guys, is still appericiated.
I'm stating this, because there are people who are trying to twist this situation out of technical facts into some religious discussion.

But you can't blame people ... On one hand Pottering is quoted in saying
Quote:

Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely


Yet also stating something along the lines that udev will always be able to build individually since it is needed for some liveCD's or something

SO on one hand it is stated he want non-sysd udev dead BUT on the other stating it will always build separate. Now the overall functionality of non-sysd udev is the big unknown... REALLY big unknown.
Sure not a problem for today, not a problem for tomorrow ... but *maybe* one in the future.

Now I am using udev and eudev (trying eudev on desktop just cause of shinies, no real preference) so its a moot point right now. But since it has been shown there is a big uncertainty surrounding non-sysd edev is it really unexpected to have some vocal complains from some?
Whether an init system should pull in udev is anothing thing, just like swallowing networking and logging (where does init end? at the wordprocessor....?) thats a different sysd discussion


I understand what you are saying, but you forgot there is an Gentoo maintainer or maintainers in-between your system and the systemd upstream. We would create a patchset that reverts such requirement if upstream developers
change the code that would prevent it's use from outside of systemd.
And if such patchset grows too large to maintain, then it's the time to fork it, not before. It's easy to miss a patch or two while tracking upstream git for patches. I'm not saying I don't trust eudev developers, all I'm saying it's easy to miss a patch or two and this is why I wouldn't trust my production machines to use it. This is my only objection to sys-fs/eudev. It was done too early and possibly unnecessarily. However, before someone twists my words again,
I'm again stating all work done by current eudev maintainers is still appericiated and anyone is welcome to use it if they want.
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4200
Location: Removed by Neddy

PostPosted: Mon Mar 03, 2014 1:44 pm    Post subject: Reply with quote

oh i'm not forgetting, I am just expressing my understanding as to a vocal opposition (NOTE how they do it, but that they are).
I sort of disagree that a fork (eudev) was done too soon. Your point that it isn't really needed right now is correct but so is the point that setting up an existing project, even if it is a proof of concept for now, has merits. What if some feature in udev that tightly tied it to sysd was released BUT it also fixed some fundamental security issue (oh I don't know some nasty node access issue) and overnight the prospect of millions of machines being vulnerable OR have to convert to sysd ... nasty.

Sure far fetched situation, but I am an engineer and I have dealt with proactive obsolescence management (with scheduled redesigns 10years down the line) & knee-jerk obsolescence management
Guess what is easier, more robust, cheaper (and not only in $).

FOr other distro's/linux users to know there is a drop-in replacement in existence is probably a good safety net for those which have not gone 100% sysd (or want a way out)
_________________
A free press is the unsleeping guardian of every other right that free men prize; it is the most dangerous foe of tyranny. Where men have the habit of liberty, the Press will continue to be the vigilant guardian of the rights of the ordinary citizen.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 1:56 pm    Post subject: Reply with quote

Naib wrote:
oh i'm not forgetting, I am just expressing my understanding as to a vocal opposition (NOTE how they do it, but that they are).
I sort of disagree that a fork (eudev) was done too soon. Your point that it isn't really needed right now is correct but so is the point that setting up an existing project, even if it is a proof of concept for now, has merits. What if some feature in udev that tightly tied it to sysd was released BUT it also fixed some fundamental security issue (oh I don't know some nasty node access issue) and overnight the prospect of millions of machines being vulnerable OR have to convert to sysd ... nasty.

Sure far fetched situation, but I am an engineer and I have dealt with proactive obsolescence management (with scheduled redesigns 10years down the line) & knee-jerk obsolescence management
Guess what is easier, more robust, cheaper (and not only in $).

FOr other distro's/linux users to know there is a drop-in replacement in existence is probably a good safety net for those which have not gone 100% sysd (or want a way out)


A patch that would fix a security vulnerability AND prevent udev's use without systemd in a same commit? I have to agree with you, it's too far fetch.
Yes, sure, as a proof of concept it's fine, but right now, in the Portage, it's causing also confusion as evident in this very thread.
People jump to an conclusion original udev is somehow deprecated when it isn't.

I don't use, or maintain eudev, yet, still, I've had to point out commits for the maintainers of it. I don't like saying this, out of respect to other developers. But to mellow it down, I'm admitting I would be propably doing exactly the same thing,
trying to follow systemd git for udev specific commits and then missing or misintepreting some. Thus, the more early, the more possibility for breakage. I'd have to personally review and compare every commit to systemd git tree since the fork was created to be able to trust it -- and still have a doubt in back of my head.
It's the human factor, as in, I wouldn't trust even myself completely.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


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

PostPosted: Mon Mar 03, 2014 2:23 pm    Post subject: Reply with quote

This reads like: reasons why udev should be a separate project.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2689

PostPosted: Mon Mar 03, 2014 2:44 pm    Post subject: Reply with quote

steveL wrote:
This reads like: reasons why udev should be a separate project.


But it's not, so the real discussion is about the best way to cope.

I could go on with comments about upstream, but that won't be helpful. The net I take out of this thread is that for the time being I'm going to stick with udev, because the maintainer's direction is acceptable to me. At some point I may have to switch to eudev, but there will most likely be sufficient warning.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4200
Location: Removed by Neddy

PostPosted: Mon Mar 03, 2014 8:22 pm    Post subject: Reply with quote

ssuominen wrote:
Naib wrote:
oh i'm not forgetting, I am just expressing my understanding as to a vocal opposition (NOTE how they do it, but that they are).
I sort of disagree that a fork (eudev) was done too soon. Your point that it isn't really needed right now is correct but so is the point that setting up an existing project, even if it is a proof of concept for now, has merits. What if some feature in udev that tightly tied it to sysd was released BUT it also fixed some fundamental security issue (oh I don't know some nasty node access issue) and overnight the prospect of millions of machines being vulnerable OR have to convert to sysd ... nasty.

Sure far fetched situation, but I am an engineer and I have dealt with proactive obsolescence management (with scheduled redesigns 10years down the line) & knee-jerk obsolescence management
Guess what is easier, more robust, cheaper (and not only in $).

FOr other distro's/linux users to know there is a drop-in replacement in existence is probably a good safety net for those which have not gone 100% sysd (or want a way out)


A patch that would fix a security vulnerability AND prevent udev's use without systemd in a same commit? I have to agree with you, it's too far fetch.
Yes, sure, as a proof of concept it's fine, but right now, in the Portage, it's causing also confusion as evident in this very thread.
People jump to an conclusion original udev is somehow deprecated when it isn't.

I don't use, or maintain eudev, yet, still, I've had to point out commits for the maintainers of it. I don't like saying this, out of respect to other developers. But to mellow it down, I'm admitting I would be propably doing exactly the same thing,
trying to follow systemd git for udev specific commits and then missing or misintepreting some. Thus, the more early, the more possibility for breakage. I'd have to personally review and compare every commit to systemd git tree since the fork was created to be able to trust it -- and still have a doubt in back of my head.
It's the human factor, as in, I wouldn't trust even myself completely.
doesn't that just show that already the lines of udev and sysd are bluring so much so that it wouldn't take too much to make it not build without sysd? how much effort by sysd maintainers would be required to obfuscate the build & patchset if already there is doubt in interpreting commits?
_________________
A free press is the unsleeping guardian of every other right that free men prize; it is the most dangerous foe of tyranny. Where men have the habit of liberty, the Press will continue to be the vigilant guardian of the rights of the ordinary citizen.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32453
Location: 56N 3W

PostPosted: Mon Mar 03, 2014 8:46 pm    Post subject: Reply with quote

Naib,

Heh and where have we seen that sort of tie in before ...
One very public example was Windows users trying to use DR-DOS under it.

udev is clearly 'end of life' - the time to be evaluating alternatives in now, unless you want to have your choice removed when udev finally vanishes into systemd.
Of course, by the time udev actually dies, there may be even more choice.

I'm running both eudev and a static /dev both of which work for me.
Static /dev takes longer to set up but it just works once its configured.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1197

PostPosted: Mon Mar 03, 2014 10:36 pm    Post subject: Reply with quote

NeddySeagoon wrote:
udev is clearly 'end of life' - the time to be evaluating alternatives in now, unless you want to have your choice removed when udev finally vanishes into systemd.

FUD

Who said this about udev?
Who maintains udev?
Who is in charge to determine who maintains udev?
_________________
fun2gen2
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32453
Location: 56N 3W

PostPosted: Mon Mar 03, 2014 10:49 pm    Post subject: Reply with quote

ulenrich,

LP has stated he looks forward to the day when udev outside of systemd is no longer supported
The Gentoo udev maintainer in Gentoo has stated he will no longer maintain udev when that time comes.

Anyone can maintain udev. It will get harder and harder to maintain once $UPSTREAM determine that udev without systemd is not supported.
It is no longer a question of if, only when.
Users who do not wish to go under the systemd steamroller need to look at alternatives well before that happens. Like now.

I guess I'm feeding the troll since you are well aware of the answers to the questions you posted. Thats why I didn't put the effort in to include any links to sources.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Guru
Guru


Joined: 25 Jul 2006
Posts: 335

PostPosted: Mon Mar 03, 2014 11:28 pm    Post subject: Reply with quote

Glad I waited until I had physical access before rebooting as eth0 disappeared. I did try adding ifnames.net=0 to the kernel line immediately after udev and it does work. However, I feared that genkernel might not propagate that line in future kernel builds, so I removed it again. I erased the file /etc/udev/rules.d/80-net-setup-link.rules which I had created as a comment per the February 25 2014 news item. That worked also.

Now running eudev and I hope it stays free of systemd. I do weekly updates for bug fixes and security fixes, not wholesale rewrites and interface changes like systemd and GNOME3.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Mar 04, 2014 5:01 am    Post subject: Reply with quote

NeddySeagoon wrote:

udev is clearly 'end of life' - the time to be evaluating alternatives in now, unless you want to have your choice removed when udev finally vanishes into systemd.


Untrue. What's your religious agenda for driving such misinformation?
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Tue Mar 04, 2014 5:21 am    Post subject: Reply with quote

ssuominen wrote:
This is my only objection to sys-fs/eudev. It was done too early and possibly unnecessarily.

This is very subjective. From my perspective it seems to be very oriented towards your position as a package maintainer. Once your job becomes too much more difficult as a package maintainer, you'd want to fork it. And that's fair enough.

On the other hand, the sentiment behind eudev and similar (polynomial-c has a more 'old-style' udev ebuild, I believe?) feels more end-user oriented. By that, I mean the driving force seems to be pointed more towards end users having a consistent experience, rather than needing to make local changes to account for, from the perspective of a user, arbitrary upstream changes. Tip of my hat to you and Jorge for trying to make sure most end users who'd disabled the old version of the 'predictable' NIC naming will still have the new version disabled, though (well, stable users, at least).

Which is better? It's pretty subjective. For my purposes, I'm a bit hesitant to thoughtlessly rely on pure upstream udev for much longer (well, I suppose I haven't been thoughtlessly relying on it for eighteen months now), as it seems much more likely that I'll need to deal with compatibility-breaking changes there. Despite that, I (so far) am still using udev on a few machines, as it hasn't broken too horridly since eudev's initial forking (which was after the NIC incident).
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Tue Mar 04, 2014 5:29 am    Post subject: Reply with quote

ssuominen wrote:
Untrue. What's your religious agenda for driving such misinformation?

It sounded, from the context, like he was referring to the comments made when udev was absorbed into systemd's repository, that it was seen as a 'dead end'. Probably that and the seeming further interconnections between systemd and udev, such as the changes to the NIC naming rules that now rely on systemd configuration files, in addition to udev configuration files. Or maybe configuration files -- I still think it's weird and wrong to stuff configs in /lib, even with being able to override them in /etc.

While it may be a bit "sky is falling!", it doesn't seem entirely unreasonable to expect that other parts of systemd will eventually be relied upon by udev. Perhaps we'd end up with a situation where systemd has to be installed for udev to work, but you don't have to run systemd to run udev? That would still technically meet systemd's loose promises of always being able to run standalone udev, yet it would be pretty intrusive on those who don't want to run systemd -- like how work on the reverse is being done, to allow those who want to run systemd on Gentoo to not have openrc installed (for functions.sh).

And to expand on that last part, it seems a bit odd that the people who want to run systemd in Gentoo want to be able to strip out all vestiges of openrc, yet the opposite is often referred to as 'childish' or similar.
Back to top
View user's profile Send private message
The Doctor
Veteran
Veteran


Joined: 27 Jul 2010
Posts: 1546

PostPosted: Tue Mar 04, 2014 6:09 am    Post subject: Reply with quote

ssuominen wrote:
NeddySeagoon wrote:

udev is clearly 'end of life' - the time to be evaluating alternatives in now, unless you want to have your choice removed when udev finally vanishes into systemd.


Untrue. What's your religious agenda for driving such misinformation?


I'd say that you should never promise what you can't keep. The fact is you can't promise that $UPSTREAM won't do such a merge. LP has made many statements to the effect that it is planned.[1] While I admire you dedication to maintaining udev, ultimately its future isn't really in your hands. If you do fork it, it won't be udev anymore. It would be something new.

I'd like to finish this post by saying that I really do appreciate the work that you and all the other devs do for gentoo. You guys are what really make it possible to have such an assume distro.

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Mar 04, 2014 6:15 am    Post subject: Reply with quote

broken_chaos wrote:
ssuominen wrote:
This is my only objection to sys-fs/eudev. It was done too early and possibly unnecessarily.

This is very subjective. From my perspective it seems to be very oriented towards your position as a package maintainer. Once your job becomes too much more difficult as a package maintainer, you'd want to fork it. And that's fair enough.

On the other hand, the sentiment behind eudev and similar (polynomial-c has a more 'old-style' udev ebuild, I believe?) feels more end-user oriented. By that, I mean the driving force seems to be pointed more towards end users having a consistent experience, rather than needing to make local changes to account for, from the perspective of a user, arbitrary upstream changes. Tip of my hat to you and Jorge for trying to make sure most end users who'd disabled the old version of the 'predictable' NIC naming will still have the new version disabled, though (well, stable users, at least).


I disagree with that definition of 'old-style'. Like the last change, in upgrade from 208 to 210, the network config changed to be a .link file, it doesn't matter where the .link file is, user has to adapt anyway, so it doesn't improve the user
experience to diverge from where upstream intended the new config to be. By definition unrequired distribution -specific changes are only misleading. Specially when the upstream location was announced to users in a Gentoo news item.
I'm not aware of anything useful in the Polynomial-C's forked ebuild, at least he hasn't asked me to merge anything over there to sys-fs/udev's ebuild that wouldn't be anything more than regular expression 's:systemd:udev:'.
If I'm wrong, please let me know, I really haven't been following that fork.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Mar 04, 2014 6:26 am    Post subject: Reply with quote

NeddySeagoon wrote:
The Gentoo udev maintainer in Gentoo has stated he will no longer maintain udev when that time comes.


Where are you getting this? I've consitently said the next step will be a patchset, if required.

NeddySeagoon wrote:
I guess I'm feeding the troll since you are well aware of the answers to the questions you posted. Thats why I didn't put the effort in to include any links to sources.


As I see it, you are the one trolling now. It's like you disregarded last ~20 posts of the thread, and started all over again.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1197

PostPosted: Tue Mar 04, 2014 9:57 am    Post subject: Reply with quote

ulenrich wrote:
NeddySeagoon wrote:
udev is clearly 'end of life' - the time to be evaluating alternatives in now, unless you want to have your choice removed when udev finally vanishes into systemd.

FUD

Who said this about udev?

LP

Quote:
Who maintains udev?

Kai Sievers

Quote:
Who is in charge to determine who maintains udev?

Kernel.org
If you state Linus is against LP
you cannot argue
udev will die
at the same time.

@NeddySeagoon
If you call me a troll
just showing the flaws of your herd
I will consider to refrain from such posts
accepting it is your new religion:
the Anti-LP church
the non believers should just respectfully ignore!
_________________
fun2gen2
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4433

PostPosted: Tue Mar 04, 2014 11:24 am    Post subject: Reply with quote

ssuominen wrote:
NeddySeagoon wrote:
The Gentoo udev maintainer in Gentoo has stated he will no longer maintain udev when that time comes.


Where are you getting this? I've consitently said the next step will be a patchset, if required.


You are doing just like LP, saying one thing and its contrary next.
Let me help your memory : http://forums.gentoo.org/viewtopic-p-7507512.html#7507512
ssuominen wrote:
I'll stop maintaining sys-fs/udev if sys-apps/systemd becomes the default

So if systemd is the default, you'll stop maintaining udev leaving every non-systemd users dead. And this could happen even before udev outside of systemd is no more support.

So keep spreading your lies and FUD on everyone, but don't touch NeddySeagoon ; punk.
(the usage of punk is an attempt to introduce some humour to calm things down ala aCOSwt style ; my next attempt would be add "Don't touch NeddySeagoon" as first CoC entry)
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 5 of 6

 
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