Truly Understanding the "Unix Philosophy" - Psychology, Philosophy, and Licenses
Users browsing this thread: 4 Guest(s)
|
|||
for what it's worth i'm pro unix philosophy and pro minimalism.
back in the day (when i used and abused windows) i was a software horder. i prided myself on always having the newest and greatest versions of everything. even if i never used or even installed them. if i needed to do mechanical drawing i had the latest autocad ready to go. if i wanted to do sound engineering i had reaper, reason, abelton, etc, etc, etc... it got so bad that i joined multiple scene release groups just so i had quicker 0day access to warez. the whole thing was based on the fact i didnt want to pay for anything. i had used linux some as a kid, and again in networking classes early in my university career, but never gave it much stock. eventually the windows world got to be too much for me. i spent more time removing and editing parts of the os than really using it. and hording all the crap wasnt doing me much good either (beyond scene cred and ridiculous torrent ratios). not sure how i got there, but one day i found myself reading about the roots of unix, free and open software, designing things with simplicity in mind. the phrase "do one thing, and do it well" then just chain multiple simple programs together to make more complex use cases really struck a cord with me. i distro hopped for a few months checking things out. trying DEs and WMs alike, seeing how each distribution was configured. but it wasnt until crunchbang really showed me what i needed to see that it clicked. if you dont know #! was just a minimal debian net install with openbox and a few xfce4 tools put together to makeup a simple system. i realized they picked a component to do each thing: openbox for wm management, tint2 for a dock and tray, networkmanager + nm-applet for networking configs, nitrogen for wallpapers, etc, etc, etc... now over time i really learned to hate most of these applications (i'm looking at you openbox and network manager) but i finally got what it was to take a minimal system and craft it exactly the way you wanted. at the end of my windows career git was brand new. and i was eager to replace svn with something better. i started using a pseudo-shell called mingw, with emulated bash in many ways. so when i switched to linux i was enthralled by the terminal. the totem of "write programs to handle text streams, because that is a universal interface" became my mantra. i tried to forsake gui applications as much as possible and focus my efforts on a shell based workflow. and minus a few applications like a web-browser, image viewer and editor, i think i've gotten pretty close. and even those, i often use tools like imagemagick from the terminal for simple edits (cropping, resizing, etc) and curl in combination with grep/sed to pull out the parts of a website i want. this is about the time i learned about nixers. jmbi taught me the difference between ricing (visually appealing tweaks to you system) and beaning (tuning how the system worked under the hook for performance and workflow). now when i design a system i try and think about the things i'm actually going to do with it, and let that define my workflow, not the possibility of something. if i need to do something new, i'll just research it and decided what the best tool for the job is when that arises. that's applied unix philosophy, in my mind at least. |
|||