not that starting to be pathetic: one guy here talking that good design and planing is nothing compared to bruteforcing random code for all the corner cases, the other says that "stable API" somehow by itself is sign of quality.
no, not the carefully designed code rapidly changing to fit present situation and having with some fallbacks but frozen API for unmaintained one-time-written third-party code to function. riiiight....
here's my example of the work of 'that' stable-API/ABI code you so adore for you:
here i have GA-MA78G-DS3H, Athlon 6000+X2, 2Gb DDR2, Radeon X4730 computer with 3 multimedia devices:
1) bt8xx-based PCI analog receiver
2) b2c2 "skystar2" DVB-S receiver
3) AVermedia AverTV USB2 analog receiver
it having Windows(tv)7(r) 64 bit and Gentoo with 2.6.36 kernel and r600g&xf86-video-ati installed.
Gentoo working flawlessly with #1 and #2. but #3 unfortunately was not reverse-engineered and there is zero feedback from manufacturer so it just dead weight.
But Windows(tm) is so cool that is has no drivers for #1 and #3 whatsoever: official support for #1 is long dropped and unofficial only consists of Vista 32 bit-capable 2005 year or something hacky thingy, #3 is not even mentioned on official website (not A8xx device) anymore. but all that is not interesting part.
the interesting part that is this Windows(tm) is unable do shutdown, reboot or otherwise properly end its existence in the system's memory. it just sitting there for 15-30 minutes and then gruesomely dies. googling revealed that this is very widespread issue and cause is some driver inconsistencies (one guy analyzed coredump from other guy's machine). in my case - b2c2 device drivers (from official page and with official support) trying do some shit with device and bus power states and repeating until OS just shoots itself (only removing them from "device list" _and_ manually removing its files from "Windows" directory helps).
potential problem is not limited to dvb or any device in particular and may happen with anyone with anything.
good fucking code practises here. i say, you love stable API/ABI ways so much - go and "marry" them, just code for OS with those and keep this shit far away from Linux.
and the next time some developer will write: "hey, guys, i think <this> can be better, just change it like this and like that. here, i got a patch for you!".
they should answer with: "are you nuts ? you can't do that, we are keeping API fidelity for dudes on the Internets! they say that is only good way for kernel development and this is only way we can find enough vendor support to run it on those pesky x86 machines we have almost 0 drivers. and we also think we should remake kernel to be micro - that will show them that we mean business"
humor us, just write your API/ABI proposal on LKML and not forget to add that entire kernel API should be like this, because it shows quality and stuff. i would really like to read some replies.
PS: and don't start that "officially supported", "discontinued", "this is third-party fault" on me or whatnot. you talking about different models, that are performance results of those models in action.
but they, probably, _just didn't tested my case_, riiight ?
no, not the carefully designed code rapidly changing to fit present situation and having with some fallbacks but frozen API for unmaintained one-time-written third-party code to function. riiiight....
here's my example of the work of 'that' stable-API/ABI code you so adore for you:
here i have GA-MA78G-DS3H, Athlon 6000+X2, 2Gb DDR2, Radeon X4730 computer with 3 multimedia devices:
1) bt8xx-based PCI analog receiver
2) b2c2 "skystar2" DVB-S receiver
3) AVermedia AverTV USB2 analog receiver
it having Windows(tv)7(r) 64 bit and Gentoo with 2.6.36 kernel and r600g&xf86-video-ati installed.
Gentoo working flawlessly with #1 and #2. but #3 unfortunately was not reverse-engineered and there is zero feedback from manufacturer so it just dead weight.
But Windows(tm) is so cool that is has no drivers for #1 and #3 whatsoever: official support for #1 is long dropped and unofficial only consists of Vista 32 bit-capable 2005 year or something hacky thingy, #3 is not even mentioned on official website (not A8xx device) anymore. but all that is not interesting part.
the interesting part that is this Windows(tm) is unable do shutdown, reboot or otherwise properly end its existence in the system's memory. it just sitting there for 15-30 minutes and then gruesomely dies. googling revealed that this is very widespread issue and cause is some driver inconsistencies (one guy analyzed coredump from other guy's machine). in my case - b2c2 device drivers (from official page and with official support) trying do some shit with device and bus power states and repeating until OS just shoots itself (only removing them from "device list" _and_ manually removing its files from "Windows" directory helps).
potential problem is not limited to dvb or any device in particular and may happen with anyone with anything.
good fucking code practises here. i say, you love stable API/ABI ways so much - go and "marry" them, just code for OS with those and keep this shit far away from Linux.
And for a start they could make an API promise for X kernel versions and see how that turns out.
they should answer with: "are you nuts ? you can't do that, we are keeping API fidelity for dudes on the Internets! they say that is only good way for kernel development and this is only way we can find enough vendor support to run it on those pesky x86 machines we have almost 0 drivers. and we also think we should remake kernel to be micro - that will show them that we mean business"
humor us, just write your API/ABI proposal on LKML and not forget to add that entire kernel API should be like this, because it shows quality and stuff. i would really like to read some replies.
PS: and don't start that "officially supported", "discontinued", "this is third-party fault" on me or whatnot. you talking about different models, that are performance results of those models in action.
but they, probably, _just didn't tested my case_, riiight ?
Comment