> be predictable
well, it is. as soon as you'll read man.
> be easy to learn
done.
> be easy to maintain
it is.
> be reliable
check
> reuse as much existing tools as possible
Yeah. We definitely should use /usr/bin/ionice instead of appropriate unit config parameter (IONice=). Who cares 90% of ionices' code is about CLI switches and environment variables handling. It's 21st century after all, our CPUs are fast enough anyway.
Posted Nov 9, 2012 21:11 UTC (Fri) by gb (subscriber, #58328)
[Link]
You see ionice? I see years of different high skilled people work and thousands lines of high-quality code.
LCE: Systemd two years on
Posted Nov 9, 2012 23:47 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
A nice argument.
"You see 1000 lines of tangled COBOL code? I see years of different high skilled people work and thousands lines of high-quality code."
LCE: Systemd two years on
Posted Nov 9, 2012 23:51 UTC (Fri) by nix (subscriber, #2304)
[Link]
You picked a really bad example. ionice.c is a mere 200 lines long, and utterly horrible (e.g. using numeric arguments where the actual interface uses a named #define, but apparently exporting that name to the user would have been too hard, just use the numbers dammit).