Announcement

Collapse
No announcement yet.

Systemd 230 Opens Up A New Graphics Vulnerability & FBDEV Still Should Die

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by SystemCrasher View Post
    Somehow, that's how software development works everywhere. Systemd isnt't unique in it. Root cause is the fact devs can't foresee everything, neither all use cases, nor all shortcomings, not to mention bugs. So if someone stumbles on bug or shortcoming, it is up to them to deal with it by default. That's how opensource works. OTOH nobody could force you to use systemd, Linux or whatever. You're perfectly free to use whatever. With some little caveat: it could turn out you have to maintain your favorite solution yourself if nobody else steps in. That's how it works.


    Nothing wrong with it. Someone have to introduce changes, and it happens all the time. I do not get why systemd devs should be unable to do something like this. Are they second-class citizens, or what? Though in this particular case they did quite strange thing. Still, fbdev appears to be poorly maintained these days. Yet it is eventually used in embedded devices, so it would be nice if there is reasonable replacement. This is especially true for small simplest i2c/spi/... LCDs where full fledged KMS driver looks like an overkill. There were patches floating around to provide simplified layer on top of KMS but it seems they haven't made it so far.
    That's funny, every time this is raised with actual OSS GPU driver devs present, the conclusion is KMS drivers are really simple if you don't need things like HW accel. I don't know which level of HW accel said devices currently have

    Comment


    • #32
      Originally posted by nanonyme View Post
      That's funny, every time this is raised with actual OSS GPU driver devs present, the conclusion is KMS drivers are really simple if you don't need things like HW accel. I don't know which level of HW accel said devices currently have
      There is one problem: "desktop GPU" devs have very specific views on simplicity. Somehow mentioned HW is so simple it only could receive few commands over I2C or SPI. It got no notion of usual DRM things like CRTC, encoder or connector. So setting up fake abstractions which do not even exist in this HW could take more than rest of code. At which point helpers aren't so helpful, etc. Somehow Intel devs and somesuch never looked into SPI or I2C LCD drivers to get idea their notion of simplicity isn't really simple by such hardware standards. There were "SimpleDRM" patches trying to address this but they've been met with "desktop" GPU devs failing to get the point due to really different notion of simplicity.

      Comment


      • #33
        Originally posted by unixfan2001 View Post
        Completely untrue, but keep the bullshit coming!
        CVE-2015-3164, CVE-2012-3524 and this phoronix article

        Originally posted by unixfan2001 View Post
        Not sure what your beef with NT is either. You do realise the Windows NT kernel is pretty advanced as far as security is concerned, right?
        yes, the kernel is really good, thanks to the DEC developers, but the final product is... nothing like Unix
        or may be would you like Linux become more closer to the Windows experiece?

        Comment

        Working...
        X