3 ms·

I'm trying to install some popular diagnostic tools, downloaded from a popular computer manufacturer, onto my laptop, using a popular install program. The insta

I'm trying to install some popular diagnostic tools, downloaded from a popular computer manufacturer, onto my laptop, using a popular install program. The install has been using 100% of a CPU for half an hour. So Greg is obviously in the dark but rather than post any actual details that could help identify and resolve the actual problem, he's decided instead to pontificate about stuff which may have nothing to do with what's really going on. This could just be a case where the installer's algorithm is fine but an underlying library call isn't working properly (for example, poll on OSX is known to have problems. http://marc.info/?l=log&m=111515776629581&w=2 http://marc.info/?l=log&m=111515776629581&w=2 ). But without some actual information, we'll never know. There seems to be no shortage of developers with poor problem solving skills.

foonamefoo 19y ago
Even if that is the case, his point still stands because someone (the OSX developers) didn't care enough about performance.
- bayareaguy 19y ago
  No, it means something may have changed in between the time the developers wrote the code and when he tried to run it. Or perhaps there's something interesting in his environment (e.g. a different file system than the installer supports). But since Greg didn't bother burdening anyone with details, we'll never know. The link I posted is a perfect example of this - it's for the supervise utility from djb's daemontools. djb is one of sharpest programmers out there but I doubt he considered that years after he wrote daemontools someone might want to run it on a platform where poll behaves as it does.