Announcement

Collapse
No announcement yet.

ACPI Updated For The Linux 3.5 Kernel

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

  • dealcorn
    replied
    Ivy Bridge Sleep/Resume?

    I ordered an Intel NUC which is like an Ivy Bridge Ultra Book without the monitor, keyboard, battery, most of the plastic that goes into the case, and a big chunk of the cost. I intend to set it up as a home, disk-less media consumption station using pxe boot. I have no idea what "initial Ivy Bridge support for the intel_idle driver" means. Might this be reasonably interpreted that starting with the 3.5 kernel, sleep to ACPI state G1/S4 and resume work even in a diskless computer?

    Leave a comment:


  • dealcorn
    replied
    Ivy Bridge Sleep/Resume?

    Duplicate post.
    Last edited by dealcorn; 28 November 2012, 08:55 AM. Reason: dp

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Hirager View Post
    Does he complain about it? After all, it is his hobby project. And he's getting paid big money for it.
    He wrote an entire distributed VCS the last time it came up.

    He created git because he was complaining that cvs/svn slowed him down too much after the developers revolted against using that proprietary app he liked.

    Edit: Hmm, maybe we really need to start pissing him off in other ways, because git turned out pretty good.

    Leave a comment:


  • Hirager
    replied
    Originally posted by smitty3268 View Post
    Burdening Linus with more bureaucratic work seems like a mistake to me.
    Does he complain about it? After all, it is his hobby project. And he's getting paid big money for it.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by WorBlux View Post
    But multiple people are less likely to make rash mistakes. You get more information and experience informing the decision. A stalement about a design decision wouldn't be the end of the world, if someone needed a feature right now, they could fork the kernel.

    In this case I think it's just a historical accident that you have one guy making the final cut because that's what he's done before, and he's done a decent job at it.
    Everyone is free to make their own decisions. It's an infinitely large pool of people making decisions. If anyone disagrees with what Linus includes in his "official" kernel, they just make their own.

    In fact, the vast majority of kernels that people use don't come from Linus at all. They come from Red Hat, Ubuntu, etc., and they all maintain their own custom patchsets that they've built on top of the one Linus ships.

    Burdening Linus with more bureaucratic work seems like a mistake to me.

    Leave a comment:


  • not.sure
    replied
    Originally posted by garegin View Post
    I think having one man reviewing every code submission for a kernel is a stupid policy. why don't they have a kernel review team like in freebsd?
    Why?

    (10 char)

    Leave a comment:


  • WorBlux
    replied
    Originally posted by Hirager View Post
    I see one more reason why the process is delegated to a single person. Humans are built such that they need a single leader to perform most efficiently. Multiple leaders introduce the risk of disagreements which slow down any process. There must be one person who has the final say on a given matter. Of course this is risky too, as despothies have showed in the history. That's what advisors are for. But again - there must be single driver for the best efficiency. I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.
    But multiple people are less likely to make rash mistakes. You get more information and experience informing the decision. A stalement about a design decision wouldn't be the end of the world, if someone needed a feature right now, they could fork the kernel.

    In this case I think it's just a historical accident that you have one guy making the final cut because that's what he's done before, and he's done a decent job at it.

    Leave a comment:


  • Hirager
    replied
    Originally posted by siride View Post
    Somewhere along the line, there has to be a final answer given as to whether something is in or out. Punting that to a committee doesn't solve the apparent problem; the people on the committee will still probably be unfamiliar with the details and may do no better than a single person who makes the final decision.
    I see one more reason why the process is delegated to a single person. Humans are built such that they need a single leader to perform most efficiently. Multiple leaders introduce the risk of disagreements which slow down any process. There must be one person who has the final say on a given matter. Of course this is risky too, as despothies have showed in the history. That's what advisors are for. But again - there must be single driver for the best efficiency. I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.

    Leave a comment:


  • siride
    replied
    Originally posted by garegin View Post
    still, he still has to "review the reviews". i don't understand the wisdom behind that.
    Somewhere along the line, there has to be a final answer given as to whether something is in or out. Punting that to a committee doesn't solve the apparent problem; the people on the committee will still probably be unfamiliar with the details and may do no better than a single person who makes the final decision.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by garegin View Post
    still, he still has to "review the reviews". i don't understand the wisdom behind that.
    He doesn't have to, he's free to to just apply everything that gets sent to him.

    The point is he is free to reject code if he feels it's in the best interests of the kernel as a whole, even when his lieutenants say the code is ready to go for their subsystem.

    In other words, he's the release manager.
    Last edited by smitty3268; 03 June 2012, 02:29 PM.

    Leave a comment:

Working...
X