User: Password:
Subscribe / Log in / New account

Some upcoming sysfs enhancements

Some upcoming sysfs enhancements

Posted Apr 20, 2006 11:21 UTC (Thu) by mic.f (guest, #30242)
In reply to: Some upcoming sysfs enhancements by bronson
Parent article: Some upcoming sysfs enhancements

What's the point in designing an API that changes every month ? This is simply useless..but kernel hackers feel so comfortable with this "perfect approach" to kernel development and they continue to reply on criticism with "use distros kernels" but how the fuck I am supposed to write a sysfs-capable app if redhat, debian, suse and every other linux distro have unaligned versions ?

IMO the reality is: developers are happy with the idea that they can change everything everytime in every place of the code BUT people and external developers and the COMMUNITY needs some sort of plan in doing this...Why larger projects do have roadmaps and the linux kernel cant ? Seems like it's because "hey im a kernel hax0r im cool lemme mess around in the code when that exciting speed enanching patch comes in or whatever new thing im happy to put in is ready, i dont care if it will break here and there"

MAYBE "ioctl -> proc -> sysfs -> NEXT_BIG_THING" could have been avoided with DESIGN DECISIONS and some planning and some middle term thinking of new kernel features..

If this is impossible to think by kernel developers, maybe a simple 6-months stable releases cycle (like gnome & co) should align distros and the community on the same kernels.. at least for some months
With a larger time frame on which a kernel is the current kernel it is supposed a lot of distros will end in picking up the same kernel thus reducing fragmentation and starting to make those "APIs" more real and useful.

(Log in to post comments)

Some upcoming sysfs enhancements

Posted Jun 1, 2006 17:55 UTC (Thu) by wilck (guest, #29844) [Link]

I full-heartedly agree.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds