Announcement

Collapse
No announcement yet.

X.Org Server Development Process Is Questioned

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

  • squirrl
    replied
    It's their model

    Something new comes along and they delete the old.

    GEM vs EXA vs XXA

    Then there was DRI vs DRI2.

    Modesetting.

    The list grows but I still blame distributions for screaming "Upstream" more than senators scream "Bipartisanship".

    It's getting old.

    You just can't keep up. I commend Nvidia for keeping up with the Jones'.

    Leave a comment:


  • Ericg
    replied
    Originally posted by uid313 View Post
    Hmm, maybe if there were a revoke() implementation as a loadable kernel module?
    That creates a problem of availability. It couldn't be used because it couldn't be guaranteed to be available. And Wayland would probably need it to be available on all systems.

    Leave a comment:


  • uid313
    replied
    Hmm, maybe if there were a revoke() implementation as a loadable kernel module?

    Leave a comment:


  • Ericg
    replied
    Originally posted by curaga View Post
    Then they'd be stuck with the inferior solution in kernel forever.
    Yuuuuuuuuuup. Remember, kernel policy is anything that ever hits mainline that userspace can use can never break. Ever. If someone wants to run a motif app from 1995 that was designed around kernel 2.4.12 (im picking a random release number there lol), that app has to work as far as the kernel is concerned. It can break because of userspace changes, thats fine, but if it can't run then it can't be because of kernel changes. If it is because of kernel changes then its considered a bug to be fixed.

    Whatever implementation of revoke() goes into the kernel has to be perfect on the first run or extensible enough to not matter.

    Leave a comment:


  • curaga
    replied
    Then they'd be stuck with the inferior solution in kernel forever.

    Leave a comment:


  • uid313
    replied
    Originally posted by daniels View Post
    They don't cover all the corner cases, some of which are viciously hard to deal with. To be honest, I think the best course of action would be an input-specific revoke(), but last time that got proposed, it got shot down in LKML internal bitchfights.
    I see.

    Maybe they should just merge something, and accept a less-than-perfect solution, so have something that kinda does what its supposed to do even if it doesn't cover all the corner cases.
    Then later it can be improved in time to mature and further stabilize.

    Leave a comment:


  • daniels
    replied
    Originally posted by uid313 View Post
    Why does not Linux have a revoke() after all these years?
    There already been patches committed to add this, why have it not been merged?
    They don't cover all the corner cases, some of which are viciously hard to deal with. To be honest, I think the best course of action would be an input-specific revoke(), but last time that got proposed, it got shot down in LKML internal bitchfights.

    Leave a comment:


  • leif81
    replied
    How about using Gerrit. Require every patch get a couple +1's before it gets (auto?) merged to master.

    Leave a comment:


  • uid313
    replied
    revoke() is available in BSD.

    Leave a comment:


  • uid313
    replied
    revoke()

    Why does not Linux have a revoke() after all these years?
    There already been patches committed to add this, why have it not been merged?

    What other operating systems or kernels beside Linux does have revoke() support?
    I heard Solaris has it, can't we just port that over to Linux?

    Leave a comment:

Working...
X