Index: libk.md
==================================================================
--- libk.md
+++ libk.md
@@ -55,16 +55,16 @@
 #### operating systems
 
 these atoms will be used to reference operating systems.
 
  * Linux: `lin`
- * Haiku: `haiku`
- * Android: `android`
+ * Haiku: `hai`
+ * Android: `and`
  * FreeBSD: `fbsd`
  * NetBSD: `nbsd`
  * OpenBSD: `obsd`
- * Darwin/Mac OS X: `dar`
+ * Darwin/Mac OS X/iOS: `dar`
  * MS-DOS: `dos`
  * FreeDOS: `fdos`
  * Windows: `win`
 
 #### file extensions
@@ -94,11 +94,11 @@
 
 libk uses a strict directory structure for code, and deviations from this structure will not be tolerated without extremely good reason.
 
 all libk code is dispersed into modules: `kcore` for internals, `kio` for I/O, `kgraft` for binary packing, etc. each module has a folder in the root directory. (libk does not have submodules.) inside each module's directory should be a header with the same name as the module (see **naming conventions** above).
 
-each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.haiku.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
+each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.hai.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
 
 each module should have a header named the same thing as the module except without the `k` prefix. (e.g. the header for `kio` is `kio/io.h`) located in its folder. this is the header that the end-user will be importing, and should handle any user-defined flags to present the API the user has selected.
 
 each module directory should contain a makefile that can build that module. see **makefiles** below. all makefiles should be named `makefile` (**not** `Makefile`).