Linked by Thom Holwerda on Thu 19th May 2011 18:59 UTC, submitted by fran
Permalink for comment 473969
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
More News »
Sponsored Links



Member since:
2005-07-07
and Lennart suggested just what phoenix suggested at the end of his comment. you just need to read whole talk.
define core abstraction of systemd interfaces which are later accessed by gnome and put them into small separate solution. which gives you:
- linux already has those so it just works
- makes them available for implementation in systems that do not have those options, they just need to implement their underlaying layer. but still much simpler than complete reimplementation in the way linux does them
same method as using abstract methods in programming. what is so strange about that?
IMHO, this move would be great. define abstraction to some feature that focuses on most users and you can focus on implementation that works. but, in OSes where it doesn't work, they just need to implement requirement in underlaying layer.
instead of looking at this like "everything but Linux will lose support", try looking from other side. coding by lowest possible denominator is always slow, inefficient and barely works. not to mention code is unreadable with #ifdefs and hacks.
now enter proposed abstract interfaces. all one needs to provide is basic fall back in the start and later reimplement it correctly. my mind tells me, that no one knows better how to do that better than FreeBSD developers alone. note that if this would be done in udev/devd time, FreeBSD would not need whole implementation, they'd only need to satisfy needs from devd