Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Bringing Up Hardware First In Linux, Then Windows

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,472

    Default Bringing Up Hardware First In Linux, Then Windows

    Phoronix: Bringing Up Hardware First In Linux, Then Windows

    After reading the Linux 2.6.37-rc3 release announcement on the Linux kernel mailing list, another interesting thread was found and it's about getting hardware vendors to do their initial hardware bring-up under Linux prior to any Microsoft Windows or Apple Mac OS X support. A number of reasons are provided why hardware vendors should support their hardware first under Linux and also why they should foster open-source drivers along with its challenges...

    http://www.phoronix.com/vr.php?view=ODgxMQ

  2. #2
    Join Date
    Nov 2010
    Posts
    4

    Thumbs down Yeah, like it was more easy.

    This is the main reason why Hardware developers doesn't make Linux's drivers:
    http://people.gnome.org/~federico/news-2009-01.html

    That simple as that, Kernel Linux doesn't have a stable API/ABI.

  3. #3
    Join Date
    Jan 2009
    Posts
    191

    Default

    no, that because hardware makers have no initiative to make quality software in general and quality drivers in particular.
    they only goal is to _make it fast_ so it will utilise all features of production hardware release _somehow_.

    but they don't take into equation fact that this software (which is necessary for utilisation of their hardware at all) also MUST be free, free "as beer". unless they selling "software-hardware complex", as they say. it would be beneficial to utilise free-as-freedom-and-as-a-beer OS for that (for many reasons which were discussed a thousand times already) in the first place.
    but managers prefer to just throw pack of money to few code monkeys in one corner and to "quality certification comity" in the other. "problem solved"

  4. #4
    Join Date
    Nov 2010
    Posts
    4

    Wink Interesting point but...

    I disagree. Mostly because IMHO the closed-source drivers and software that I use on Windows works just fine. From Synaptics to Catalyst, my hardware works and I can cofigure how will work.

    But on Linux distributions, there are tree problems. First, the lack of software that configure how my hardware will work. Simple things like a touchpad configuration interface are just missing. Second, obviously, when the driver don't work correctly. The other problem is when some software doesn't work well with the hardware, like Ubuntu Unity with ATi graphics.

    Two of these problems will be solved if the hardware vendors make drivers for Linux distributions. And it doesn't need to be open source drivers to do so, just good drivers. Saddly, Hardware vendors have two reasons why this can't be done, because Linux distributions' market isn't redituable and because Linux hasn't a stable API/ABI and Linux distributions lacks of , so technically they have to create a driver for every kernel version, for every distro.

  5. #5
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    446

    Default

    Quote Originally Posted by JairJy View Post
    Linux hasn't a stable API/ABI and Linux distributions lacks of , so technically they have to create a driver for every kernel version, for every distro.
    Uh, no they don't. They just need to release the source so it goes into the kernel and is updated as required for API changes.

    Stable APIs are the reason why Windows is such a colossal pile of security holes; they're the last thing Linux needs.

  6. #6
    Join Date
    Dec 2007
    Posts
    2,279

    Default

    Quote Originally Posted by movieman View Post
    Uh, no they don't. They just need to release the source so it goes into the kernel and is updated as required for API changes.
    For the upstream kernel, yes; except that no distro ships the upstream kernel, so tons of stuff has to get backported for every distro. Either the distro or the hw vendor has to deal with it if they want the hw to work on a particular distro version.

  7. #7
    Join Date
    Nov 2010
    Posts
    4

    Unhappy LinuxIsPerfect(TM) it doesn't need to change but others has to.

    Quote Originally Posted by movieman View Post
    Uh, no they don't. They just need to release the source so it goes into the kernel and is updated as required for API changes.

    Stable APIs are the reason why Windows is such a colossal pile of security holes; they're the last thing Linux needs.
    LinuxIsPerfect(TM) it doesn't need to change but others has to. Isn't any wonder why Linux distros are the last OSes that have drivers, that's because these oses have the only kernel that forces the hardware vendors to have to release the source of their drivers so they can be update with the kernel releases.

    And of curse, Linux doesn't need a stable API/ABI to have security holes. Like this one, most of them doesn't require it.

  8. #8
    Join Date
    Oct 2009
    Posts
    111

    Default

    Quote Originally Posted by movieman View Post
    Uh, no they don't. They just need to release the source so it goes into the kernel and is updated as required for API changes.

    Stable APIs are the reason why Windows is such a colossal pile of security holes; they're the last thing Linux needs.
    I don't think so.
    Isn't it interesting that here are talks that proprietary stuff has worse code quality and at the same time the kernel folks do not manage to provide a stable API?

    Is _their_ code quality so bad that they fear a stable API? Maybe they should learn to promise something themselves instead of asking others to do just that.

    And for a start they could make an API promise for X kernel versions and see how that turns out.

  9. #9
    Join Date
    Jan 2009
    Posts
    191

    Default

    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 for a start they could make an API promise for X kernel versions and see how that turns out.
    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 ? ;)

  10. #10
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,766

    Default

    Quote Originally Posted by movieman View Post
    Uh, no they don't. They just need to release the source so it goes into the kernel and is updated as required for API changes.
    You're so smart, aren't you.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •