Is 4540s still the easiest?

[thecrusher]

SUCCESS!!! You are a genius, and so are all the other people that have created this little corner of the universe. For the record, I remembered to set the display type on the patching options the first time, but missed it the second time. It's a tough set of details to get through perfectly, and it seems like there should be some sort of software solution to guide me through it.

Everything seems to work so far. Except wifi, most likely because the new card is still in California (but hey, wireless, right?

Here's one bit of oddness I've noticed a couple of times - I list the contents of a mounted volume in terminal, and it does not show a complete list of files. I immediately list again, and the files are all there. I know I saw this on the CarbConfig-mounted EFI directory and I think I saw this happen on my thumb drive too. Has anyone else seen anything like this?

Thanks!

 

[nguyenmac]

SUCCESS!!! You are a genius, and so are all the other people that have created this little corner of the universe. For the record, I remembered to set the display type on the patching options the first time, but missed it the second time. It's a tough set of details to get through perfectly, and it seems like there should be some sort of software solution to guide me through it.

Really, we make it fool-proof as possible, even highlight it, but...

If selecting options is already tough for you, I doubt you're suitable for Hackintosh world.

 

[RehabMan]

... It's a tough set of details to get through perfectly, and it seems like there should be some sort of software solution to guide me through it.

The "software" between your ears should be better utilized.

Following the guide with care and patience is required.

 

[thecrusher]

Really, we make it fool-proof as possible, even highlight it, but...

If selecting options is already tough for you, I doubt you're suitable for Hackintosh world.

The "software" between your ears should be better utilized.

Following the guide with care and patience is required.

You guys are hilarious. You should start your own comedy team.

I mean, you were joking right? Because I've forgotten more install processes in my 30 year career as a a UNIX/Mac sysadmin and developer than you'll ever even see. A career that includes kernel debugging, and device driver assembly code. And thousands of different install processes requiring all levels of exacting execution.

It's a career that also includes expertise in human factors design.

One classic example in human factors is a door design that puts vertical handles on both sides of a door (because it looks good) and then puts signs on both sides of the door, one that says "pull" and the other "push". A very high percentage of new users of this door are going to grab that vertical bar and pull on the push side. And when that happens the designer perhaps mocks the stupidity of the users (and the users generally feel stupid too).

And yet it's a guaranteed fact that a high percentage of people are going to miss the sign and pull the door. So all this designer has really done is design a door to his own personal aesthetic, and ignored the functional use. The reality is that this is a bad door design.

Look around these forums. There's countless users committing the same mistakes, over and over again. You can condescend all you want about how smart you are and how dumb we are, but it's all tangible proof that this process has many opportunities for improvements.

I know you guys work hard on all of this. And you've moved mountains. Great. I'll praise you all you want for that. And a few hours ago, I would have been willing to help. But what you just did here is just petty, childish, unprofessional nonsense that has nothing to do with software development, and so I rather doubt I can be of any service.

 

[RehabMan]

...
Look around these forums. There's countless users committing the same mistakes, over and over again. You can condescend all you want about how smart you are and how dumb we are, but it's all tangible proof that this process has many opportunities for improvements.

I know you guys work hard on all of this. And you've moved mountains. Great. I'll praise you all you want for that. And a few hours ago, I would have been willing to help. But what you just did here is just petty, childish, unprofessional nonsense that has nothing to do with software development, and so I rather doubt I can be of any service.

I'll try to explain quickly and succinctly...

My post count: 55,425 (now 55,426)
Your post count: 7

As you can imagine, many of those 55,425 posts are to provide an answer to the same question that has been asked and answered possibly hundreds of times. Many of the answers are provided in the various guides readily available (in sticky threads), and easily found with search and a bit of time reading.

So yes, partly joking. Gotta break up the monotony somehow...

You should not expect this to be super easy and to be done all automatically by software. Tools like the ProBook Installer automate many tasks which would take someone new possibly weeks (or more... definitely more) to learn. But you do have to spend the time carefully reading the documentation that is provided and paying careful attention to what you're doing. It is not surprising that at one's first attempt there are mistakes. What is surprising is that most don't go back and read carefully, trying it a second (or third) time on their own, before asking for help or claiming "it doesn't work."

 

[nguyenmac]

You guys are hilarious. You should start your own comedy team.

I mean, you were joking right? Because I've forgotten more install processes in my 30 year career as a a UNIX/Mac sysadmin and developer than you'll ever even see. A career that includes kernel debugging, and device driver assembly code. And thousands of different install processes requiring all levels of exacting execution.

It's a career that also includes expertise in human factors design.

One classic example in human factors is a door design that puts vertical handles on both sides of a door (because it looks good) and then puts signs on both sides of the door, one that says "pull" and the other "push". A very high percentage of new users of this door are going to grab that vertical bar and pull on the push side. And when that happens the designer perhaps mocks the stupidity of the users (and the users generally feel stupid too).

And yet it's a guaranteed fact that a high percentage of people are going to miss the sign and pull the door. So all this designer has really done is design a door to his own personal aesthetic, and ignored the functional use. The reality is that this is a bad door design.

Look around these forums. There's countless users committing the same mistakes, over and over again. You can condescend all you want about how smart you are and how dumb we are, but it's all tangible proof that this process has many opportunities for improvements.

I know you guys work hard on all of this. And you've moved mountains. Great. I'll praise you all you want for that. And a few hours ago, I would have been willing to help. But what you just did here is just petty, childish, unprofessional nonsense that has nothing to do with software development, and so I rather doubt I can be of any service.

You and all people can do me a favor, reading the guide and tool carefully, and I can live more peacefully, really.

Dealing with this EVERYDAY makes me lose patience and be angry for nothing, and it's not good for my health.

 

[thecrusher]

As you can imagine, many of those 55,425 posts are to provide an answer to the same question that has been asked and answered possibly hundreds of times. Many of the answers are provided in the various guides readily available (in sticky threads), and easily found with search and a bit of time reading.

I don't have to imagine. I've seen you answer these questions over and over again. Frankly I'm impressed at how quickly you response. But this quick response also means something else: these problems are easy to diagnose. Therefore, diagnosis could be automated. As far as things being easy to find with search and reading, "easy" is relative. More on that below.

You should not expect this to be super easy and to be done all automatically by software. Tools like the ProBook Installer automate many tasks which would take someone new possibly weeks (or more... definitely more) to learn. But you do have to spend the time carefully reading the documentation that is provided and paying careful attention to what you're doing. It is not surprising that at one's first attempt there are mistakes. What is surprising is that most don't go back and read carefully, trying it a second (or third) time on their own, before asking for help or claiming "it doesn't work."

I'm not surprised that it seems to you that people don't take the time to do that. I certainly have been doing nothing else except that for a couple of days. Here's the thing, as soon as you go outside the script, there's nothing in your documentation or software chain that actually gets users back on track. With luck, you can use a search, and if you happen to phrase a question in your head with the same keywords as someone else who made the exact same mistake on the exact same system, you might find the solution. But other than that, honestly, the system seems to be designed with you as part of the automation.

Take the "F4" mistake I made as an example. The install guide does make it bold and red, but doesn't bother explaining what the purpose is. So if you misread this as F9, there's nothing in that document that's every going to get you back on track again (and yes I saw your latest red documentation changes). And there's no likely search that's going to lead you to the answer.

So what about my expectation for things to be easy? It's precisely because I'm aware of how much time you spend answering seemingly stupid questions from seemingly lazy users that I'm surprised you aren't interested in discussing ways to improve the process. I expect that things which are easy to fix should be fixed, because that's good practice. Why does probook installer proceed at all if I never pressed F4? This should be trivial to detect, and to throw an error with instructions. Not many things in coding are literally five minutes of work, but this would be. And when I have to select either low or high resolution display for this to work, why is selecting nothing even an option? This is exactly the sort of user interface mistake that's human factors 101: don't set traps for your users, and then be surprised they get stuck in those traps.

I might hazard a guess that the choice of using an installer itself to do the configuration work leads to some of these design choices. I can see the attraction in using this to simplify the creation of a user interface and also because the configuration process is quite similar to a software installation. I'd much recommend a tcl/tk or python/tk script wrapped up as an application to handle this, because that can provide the step-by-step interaction that would be ideal here. But even if we ignore that as too much work, the installer method could be modified with preflight and postflight scripts that would perform a series of checks that would save both you and the users a ton of time and energy.

Let me generalize even further: This bulk of the installation process could be EASILY streamlined into this:

1. Run a thumbdrive builder
2. Change the BIOS
3. Boot once from USB, perform OS X install
4. Boot again, press F4
5. Run the clover probook installer, only a version with no user traps

Let's talk about this. The thumbdrive builder could partition and format the thubmdrive, prompt the user about their system, and copy in appropriate clover and config files. It could also add a probook installer app to the thumb drive itself, so that it would be installed during the Yosemite install. In fact, it could ask all the questions up front, and preconfigure the probook installer application with the right settings to finish the install free of any interactions.

I also suspect that you could eliminate step four by including some cookie during thumb drive setup that would be noticed by the bootloader causing it to do the needed dump with no user intervention. And if that's the case then you could also fully automate the running of the preconfigured probook installer as a postinstall of the yosemite install. In that case this would be the full process:

1. Run a thumbdrive builder and preconfigure all of your settings with sanity checks that keep users from shooting themselves in the foot and don't require any careful reading at all
2. Fix the BIOS
3. Boot once from USB and follow the usual yosemite install steps

Let me know if you want me to get started on this thumbdrive setup program.

 

[RehabMan]

...Here's the thing, as soon as you go outside the script,

And that's the key. Unless you know what you're doing, don't "go outside the script"...

Take the "F4" mistake I made as an example. The install guide does make it bold and red, but doesn't bother explaining what the purpose is. So if you misread this as F9, there's nothing in that document that's every going to get you back on track again (and yes I saw your latest red documentation changes). And there's no likely search that's going to lead you to the answer.

This is where re-reading it and doing it again can be the solution. Assumption that "I did something wrong" vs. "there's a flaw in the written process or flaw in the software provided." I know... I'm living in dreamland. Not everyone operates as I do...

So what about my expectation for things to be easy? It's precisely because I'm aware of how much time you spend answering seemingly stupid questions from seemingly lazy users that I'm surprised you aren't interested in discussing ways to improve the process.

It is nguyenmac's installer, not mine. I don't even use the installer...

Why does probook installer proceed at all if I never pressed F4?

Because DSDT does not need to be patched every time PBI-CE is used.

This should be trivial to detect, and to throw an error with instructions.

It already does this (or used to). People ignore(d) the error.

Not many things in coding are literally five minutes of work, but this would be. And when I have to select either low or high resolution display for this to work, why is selecting nothing even an option?

Some things like that are not as easy to implement (as you might think) within the framework provided by the OS X installer. Bottom line is these tools are developed for free by users in their spare time.

Let me generalize even further: This bulk of the installation process could be EASILY streamlined into this:

1. Run a thumbdrive builder
2. Change the BIOS
3. Boot once from USB, perform OS X install
4. Boot again, press F4
5. Run the clover probook installer, only a version with no user traps

Let's talk about this. The thumbdrive builder could partition and format the thubmdrive, prompt the user about their system, and copy in appropriate clover and config files. It could also add a probook installer app to the thumb drive itself, so that it would be installed during the Yosemite install. In fact, it could ask all the questions up front, and preconfigure the probook installer application with the right settings to finish the install free of any interactions.

You're welcome to write your own. The source is available. Perhaps you can be the person with the "better mousetrap."

Over time, I've actually become somewhat opposed to automatic installers. They take away a part of the process which I feel is important: learning how it works. More automation will lead to just more users who don't have the slightest idea about how hackintosh works.

I also suspect that you could eliminate step four by including some cookie during thumb drive setup that would be noticed by the bootloader causing it to do the needed dump with no user intervention. And if that's the case then you could also fully automate the running of the preconfigured probook installer as a postinstall of the yosemite install. In that case this would be the full process:

I assume you meant "eliminate pressing F4". It would require changes to the Clover bootloader, which is a separate project by entirely different developers.

Running the ProBook Installer automatically is not possible as the install of OS X is vanilla.

 

[nguyenmac]

I don't have to imagine. I've seen you answer these questions over and over again. Frankly I'm impressed at how quickly you response. But this quick response also means something else: these problems are easy to diagnose. Therefore, diagnosis could be automated. As far as things being easy to find with search and reading, "easy" is relative. More on that below.



I'm not surprised that it seems to you that people don't take the time to do that. I certainly have been doing nothing else except that for a couple of days. Here's the thing, as soon as you go outside the script, there's nothing in your documentation or software chain that actually gets users back on track. With luck, you can use a search, and if you happen to phrase a question in your head with the same keywords as someone else who made the exact same mistake on the exact same system, you might find the solution. But other than that, honestly, the system seems to be designed with you as part of the automation.

Take the "F4" mistake I made as an example. The install guide does make it bold and red, but doesn't bother explaining what the purpose is. So if you misread this as F9, there's nothing in that document that's every going to get you back on track again (and yes I saw your latest red documentation changes). And there's no likely search that's going to lead you to the answer.

So what about my expectation for things to be easy? It's precisely because I'm aware of how much time you spend answering seemingly stupid questions from seemingly lazy users that I'm surprised you aren't interested in discussing ways to improve the process. I expect that things which are easy to fix should be fixed, because that's good practice. Why does probook installer proceed at all if I never pressed F4? This should be trivial to detect, and to throw an error with instructions. Not many things in coding are literally five minutes of work, but this would be. And when I have to select either low or high resolution display for this to work, why is selecting nothing even an option? This is exactly the sort of user interface mistake that's human factors 101: don't set traps for your users, and then be surprised they get stuck in those traps.

I might hazard a guess that the choice of using an installer itself to do the configuration work leads to some of these design choices. I can see the attraction in using this to simplify the creation of a user interface and also because the configuration process is quite similar to a software installation. I'd much recommend a tcl/tk or python/tk script wrapped up as an application to handle this, because that can provide the step-by-step interaction that would be ideal here. But even if we ignore that as too much work, the installer method could be modified with preflight and postflight scripts that would perform a series of checks that would save both you and the users a ton of time and energy.

Let me generalize even further: This bulk of the installation process could be EASILY streamlined into this:

1. Run a thumbdrive builder
2. Change the BIOS
3. Boot once from USB, perform OS X install
4. Boot again, press F4
5. Run the clover probook installer, only a version with no user traps

Let's talk about this. The thumbdrive builder could partition and format the thubmdrive, prompt the user about their system, and copy in appropriate clover and config files. It could also add a probook installer app to the thumb drive itself, so that it would be installed during the Yosemite install. In fact, it could ask all the questions up front, and preconfigure the probook installer application with the right settings to finish the install free of any interactions.

I also suspect that you could eliminate step four by including some cookie during thumb drive setup that would be noticed by the bootloader causing it to do the needed dump with no user intervention. And if that's the case then you could also fully automate the running of the preconfigured probook installer as a postinstall of the yosemite install. In that case this would be the full process:

1. Run a thumbdrive builder and preconfigure all of your settings with sanity checks that keep users from shooting themselves in the foot and don't require any careful reading at all
2. Fix the BIOS
3. Boot once from USB and follow the usual yosemite install steps

Let me know if you want me to get started on this thumbdrive setup program.

Very nice idea, I hope I could do this, but I'm not free now, I have many works and study to do. Now I only have time to improve the stability of Hackintosh on supported models, and it already took tons of time...

You're free to help us. The source is available on github. If you're willing to help, I can answer any questions.

About the F4 thing, it reported the error that user did not press F4 in past version of PBI CE. Result: Many people ignored the error and still asking questions why audio and other things can work, until I told them to press F4. Then, we had to find a workaround way to make F4 unnecessary in some cases, and it reduces lots of questions like that.

Also, you tell me to reduce the guide to this "Boot once from USB, perform OS X install"? Then I will have to answer questions like this:
- How to passby the screen showing keyboard and mouse?
- Why can't PBI CE run on my system (because they does not format their drive to GPT).
- After first install (first stage), my hard drive does not show up (yeah, you have to select USB to complete second stage).

That's why I try to explain as much detail as possible in the guide already, just to prevent them from asking.

 

[thecrusher]

Also, you tell me to reduce the guide to this "Boot once from USB, perform OS X install"? Then I will have to answer questions like this:
...
That's why I try to explain as much detail as possible in the guide already, just to prevent them from asking.

I didn't mean that should literally be the text of a new guide, I was simply trying to illustrate how many steps could be removed from the process with some relatively simple improvements.

Another lesson from human factors - at some point, adding more text does not result in less errors. We will always have errors of misreading or skipping text. It's not just a TL;DR culture (Too Long; Didn't Read). Even if a user is diligent (as I believe I was) errors will occur. And yet another lesson from human factors - once a human has made an error once (misreading F4 as F9), they will usually continue to make the very same error repeatedly. These are all just known errors in human beings that we need to program around.

I hope to find time to take a crack at the easiest part of this process - an application to handle steps one and two to create an install thumb drive. It could later be expanded to include the additional features.