On Sat, 25 Apr 2015 16:40:51 +0000, Laeeth Isharc wrote: > On Saturday, 25 April 2015 at 16:10:11 UTC, ketmar wrote: >> On Sat, 25 Apr 2015 14:19:30 +0000, Laeeth Isharc wrote: >> >>> But surely, it would be a start to make it easy for the user to know >>> so she can shape her approach accordingly. >> >> i believe that this must be controlled with `version` or cli arg, and >> it belongs to application logic, not standard library. > > > I defer to your greater expertise. > > But I should have thought that if csv parsing belongs in a standard > library (something that is easy for a user to write himself) then > detecting whether a path is on an SSD might perhaps too. (Bearing in > mind it's more of a system thing not so easy for every user to write > himself in a platform independent way).
and now something more serious: trying to detect what storage propgram using is completely unreliable. you can't optimise for all cases, and you can't even detect all cases. big raid which can be faster than SSD with "SSD pattern"? ah, ok, nobody cares, we detected it as HDD. virtual drive, which can be anything at all? fuse mount point? i can think out alot of that. that's why operational mode should be controlled by cli switch. if user *really* cares about performance, he *will* know what HW he has and how to make program fully utilize it. and in other cases let OS i/o scheduler do it work without trying to needlessly "help" it.
signature.asc
Description: PGP signature
