From 354e98325fe94f4834d360086a67d0032b83fa20 Mon Sep 17 00:00:00 2001 From: bnewbold Date: Sun, 24 Jan 2010 05:56:09 -0500 Subject: syntax fixes --- software/MOSS.page | 149 ++++++++++++++++++----------------- software/freebsd-tricks.page | 6 +- software/functional programming.page | 38 ++++----- software/ruby.page | 41 +++++----- software/scheme.page | 4 +- software/server-setup.page | 2 +- software/unix-tricks.page | 2 +- tmp/Newcomb paradox.page | 69 ---------------- tmp/Saccade.page | 7 -- tmp/Teaching CS.page | 102 ------------------------ tmp/Topics of Curiosity.page | 54 ------------- tmp/newcomb-paradox.page | 69 ++++++++++++++++ tmp/teaching-cs.page | 102 ++++++++++++++++++++++++ tmp/topics-of-curiosity.page | 54 +++++++++++++ 14 files changed, 349 insertions(+), 350 deletions(-) delete mode 100644 tmp/Newcomb paradox.page delete mode 100644 tmp/Saccade.page delete mode 100644 tmp/Teaching CS.page delete mode 100644 tmp/Topics of Curiosity.page create mode 100644 tmp/newcomb-paradox.page create mode 100644 tmp/teaching-cs.page create mode 100644 tmp/topics-of-curiosity.page diff --git a/software/MOSS.page b/software/MOSS.page index 95f2d41..c0bba84 100644 --- a/software/MOSS.page +++ b/software/MOSS.page @@ -18,86 +18,91 @@ and user management, continuation-based serializable programming, persistent data accessibility, file and process versioning, central foreign function management, and code/content distribution. It'll be easy! -.. topic:: Implementation +Implementation +~~~~~~~~~~~~~~~ - Moss would probably start as "stuff": middleware, userland applications, - utilities, and native shell and GUI interfaces. It could also be a - separate hosted virtual machine, a monolithic application, a kernel - extension, or ultimately run alone over a high performance shim host OS. +Moss would probably start as "stuff": middleware, userland applications, +utilities, and native shell and GUI interfaces. It could also be a +separate hosted virtual machine, a monolithic application, a kernel +extension, or ultimately run alone over a high performance shim host OS. - Distribution would be self hosting and viral: users would replicate a copy - of the system from a friend instead of from a central server, patches - and applications would be distributed word-of-mouth, and trust networks - would form naturally via this distribution. Customization and feature sets - would be passed on, which makes it likely that a user would receive a - system already tweaked for their own needs and computing knowledge level. +Distribution would be self hosting and viral: users would replicate a copy +of the system from a friend instead of from a central server, patches +and applications would be distributed word-of-mouth, and trust networks +would form naturally via this distribution. Customization and feature sets +would be passed on, which makes it likely that a user would receive a +system already tweaked for their own needs and computing knowledge level. - *Existing Projects:* Inferno, Xen, vmware, Java, GNU/* +*Existing Projects:* Inferno, Xen, vmware, Java, GNU/* -.. topic:: Universal, distributed file system +Universal, distributed file system +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - The core of the system would be a universally accessible identity-based - operating system. Some authoritive domain would probably be required, but - public identity brokers would allow anonymous identities. "Strong - Cryptography" is a goal, allowing a user's content to be hosted/cached - on third party machines in an encrypted form. The real challenge of course - is a flexible crypto system than can be transitioned or upgraded if a flaw - is discovered without total data loss. +The core of the system would be a universally accessible identity-based +operating system. Some authoritive domain would probably be required, but +public identity brokers would allow anonymous identities. "Strong +Cryptography" is a goal, allowing a user's content to be hosted/cached +on third party machines in an encrypted form. The real challenge of course +is a flexible crypto system than can be transitioned or upgraded if a flaw +is discovered without total data loss. - My dream path would look something like:: +My dream path would look something like:: - /net/user@some.domain.tld/media/ledzep/tangerine.mp3 + /net/user@some.domain.tld/media/ledzep/tangerine.mp3 - From the application end there would be no concept of "local" or "remote" - files to a particular machine, though perhaps some feedback on access time. - So, for instance, once tokens/authentication is handled, user utilities - like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``. +From the application end there would be no concept of "local" or "remote" +files to a particular machine, though perhaps some feedback on access time. +So, for instance, once tokens/authentication is handled, user utilities +like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``. - Versioning, write locks, etc would have to be considered. +Versioning, write locks, etc would have to be considered. - *Existing projects:* OpenAFS, freeNet, ssh, kerberos, git +*Existing projects:* OpenAFS, freeNet, ssh, kerberos, git -.. topic:: Serializable Programs - - The state/continuation/environment of a running program or chain of - programs should be a "first level object": a bundle of data like any other - that can be transmitted, copied, and stored away for later. A user should - be able to drag an entire application running on a desktop computer - onto their laptop when then need to travel, or from laptop to workstation - if then need additional computing power. Distributed computing could be - implemented by bundling up applets that are shot off to a cluster or - higher performance computer for processing, and the result state of the - program would simply be bundled back to the requesting client. Such bundles - wouldn't be very large: data would be stored on the distributed filesystem, - which appears identical (*exactly?*) to every node on the network. - - Properly written, such a serializable system could also lead to performance - and power consumption savings by swapping idle programs and processes to - disk, or let low-usage nodes shift their processes off to other nodes - and power down. - - *Existing Projects:* Lisp, Stackless - -.. topic:: Foreign Function Management - - It would be nice to see a move away from the library model for shared - code to a more flexible/dynamic foreign function interface that would - allow any appropriate code to announce its availability to other - applications regardless of version, platform, coding language, etc. - This would be a high-level feature, not intended to replace kernel level - operations (read/write) but to make package/library management easier - (it doesn't matter if an image conversion function is coming from a video - editing package or libpng as long as it reads a raw array and returns - a binary stream). - - There's room for dynamic optimization here: if program - realizes it's native string manipulation library sucks for 5meg+ datasets - it could look through the library and see if there's a better one. - - *And,* this too could be distributed, allowing super easy access to - distributed computing resources; underutilized nodes could make their - functions available to nearby nodes, or a machine with tons of matrix - crunching silicon (eg high end video cards) could swap work units - with a machine with a dedicated crypto chip or 64bit+ processor. - - *Existing Projects:* Script-fu from the Gimp +Serializable Programs +~~~~~~~~~~~~~~~~~~~~~~~ + +The state/continuation/environment of a running program or chain of +programs should be a "first level object": a bundle of data like any other +that can be transmitted, copied, and stored away for later. A user should +be able to drag an entire application running on a desktop computer +onto their laptop when then need to travel, or from laptop to workstation +if then need additional computing power. Distributed computing could be +implemented by bundling up applets that are shot off to a cluster or +higher performance computer for processing, and the result state of the +program would simply be bundled back to the requesting client. Such bundles +wouldn't be very large: data would be stored on the distributed filesystem, +which appears identical (*exactly?*) to every node on the network. + +Properly written, such a serializable system could also lead to performance +and power consumption savings by swapping idle programs and processes to +disk, or let low-usage nodes shift their processes off to other nodes +and power down. + +*Existing Projects:* Lisp, Stackless + +Foreign Function Management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It would be nice to see a move away from the library model for shared +code to a more flexible/dynamic foreign function interface that would +allow any appropriate code to announce its availability to other +applications regardless of version, platform, coding language, etc. +This would be a high-level feature, not intended to replace kernel level +operations (read/write) but to make package/library management easier +(it doesn't matter if an image conversion function is coming from a video +editing package or libpng as long as it reads a raw array and returns +a binary stream). + +There's room for dynamic optimization here: if program +realizes it's native string manipulation library sucks for 5meg+ datasets +it could look through the library and see if there's a better one. + +*And,* this too could be distributed, allowing super easy access to +distributed computing resources; underutilized nodes could make their +functions available to nearby nodes, or a machine with tons of matrix +crunching silicon (eg high end video cards) could swap work units +with a machine with a dedicated crypto chip or 64bit+ processor. + +*Existing Projects:* Script-fu from the Gimp + diff --git a/software/freebsd-tricks.page b/software/freebsd-tricks.page index 37a3a5e..80c29d1 100644 --- a/software/freebsd-tricks.page +++ b/software/freebsd-tricks.page @@ -13,15 +13,15 @@ See also `unix `_ and Set User Shell ----------------------- ``bash`` isn't always installed, so the default user shell is ``sh``; after -``bash`` is installed, a user can change their login shell with the command: +``bash`` is installed, a user can change their login shell with the command:: -$ chsh -s /usr/local/bin/bash + $ chsh -s /usr/local/bin/bash Burn an ISO image ----------------------- To burn a CD-R, use ``burncd`` like so:: -$ burncd -f /dev/acd0 data FILENAME.iso fixate + $ burncd -f /dev/acd0 data FILENAME.iso fixate Network Tools ---------------------- diff --git a/software/functional programming.page b/software/functional programming.page index 593cf41..7fa1358 100644 --- a/software/functional programming.page +++ b/software/functional programming.page @@ -24,31 +24,31 @@ or variables in layer after layer of functions and just holding on to the outermost layer. For instance, the typical way to write a ``length`` function in python would be:: ->>> def how-long(x): ->>> l = 0 ->>> while x.has_next() ->>> l = l+1; ->>> x.pop() ->>> return l + def how-long(x): + l = 0 + while x.has_next() + l = l+1; + x.pop() + return l Using recursion, we could do:: ->>> def how-long-recurse(x): ->>> if x.has_next() ->>> x.pop() ->>> return how-long-recurse(x) + 1 ->>> else ->>> return 0 + def how-long-recurse(x): + if x.has_next() + x.pop() + return how-long-recurse(x) + 1 + else + return 0 Using the collector paradigm, we could do:: ->>> def add1(x): return a+1; ->>> def how-long-col(x, col): ->>> if x.has_next() ->>> return col(0) ->>> else ->>> x.pop() ->>> return how-long-col(x, lambda a: col(add1(a))) + def add1(x): return a+1; + def how-long-col(x, col): + if x.has_next() + return col(0) + else + x.pop() + return how-long-col(x, lambda a: col(add1(a))) The first two ways, the plus one operation is actually executed at any given time, while with the collector implementation we're really creating a diff --git a/software/ruby.page b/software/ruby.page index c044a48..662d934 100644 --- a/software/ruby.page +++ b/software/ruby.page @@ -7,7 +7,7 @@ toc: no Ruby ================== -.. note:: This information is very rough, it's mostly my notes about what is +Note: this information is very rough, it's mostly my notes about what is different about Ruby syntax compared to similar modern interpreted pan-paradigm languages like Python. @@ -24,17 +24,17 @@ order data type. Ranges ---------- - ->>> 2..7 # => 2..7 ->>> (2..7).to_a # => [2, 3, 4, 5, 6, 7] ->>> (2...7).to_a # => [2, 3, 4, 5, 6] ->>> ('e'..'h').to_a # => ["e", "f", "g", "h"] +:: + 2..7 # => 2..7 + (2..7).to_a # => [2, 3, 4, 5, 6, 7] + (2...7).to_a # => [2, 3, 4, 5, 6] + ('e'..'h').to_a # => ["e", "f", "g", "h"] Control Structures -------------------- Can use ``if`` after a statement:: ->>> a = c if c > b + a = c if c > b Along with the usual ``break`` and ``next``, there is ``redo`` which redoes the current loop (initial conditions may have been changed). @@ -45,28 +45,29 @@ Boolean Operators Anything that is not ``nill`` or ``false`` is true. To force interpretation as boolean, use ``!!`` (not not):: ->>> !!(nil) # => false ->>> !!(true) # => true ->>> !!('') # => true ->>> !!(0) # => true ->>> !!({}) # => true + !!(nil) # => false + !!(true) # => true + !!('') # => true + !!(0) # => true + !!({}) # => true Misc ---------------- Can use nasty Perl style regular expression stuff:: ->>> re1 = /\d+/ ->>> "There are 5 kilos of chunky bacon on the table!" =~ re1 # => 10, the index ->>> $~ # => # ->>> $~.pre_hash # => "There are " + re1 = /\d+/ + "There are 5 kilos of chunky bacon on the table!" =~ re1 # => 10, the index + $~ # => # + $~.pre_hash # => "There are " Also $1, $2, etc. The "splat operator", '*', either collects or expands extra arguments depending on syntax (I think this is kind of icky):: ->>> a, b = 1, 2, 3, 4 # a=1, b=2 ->>> a, *b = 1, 2, 3, 4 # a=1, b=[2,3,4] ->>> c, d = 5, [6, 7, 8] # c=5, d=[6,7,8] ->>> c, d = 5, *[6, 7, 8] # c=5, b=6 + a, b = 1, 2, 3, 4 # a=1, b=2 + a, *b = 1, 2, 3, 4 # a=1, b=[2,3,4] + c, d = 5, [6, 7, 8] # c=5, d=[6,7,8] + c, d = 5, *[6, 7, 8] # c=5, b=6 + diff --git a/software/scheme.page b/software/scheme.page index 8c719ca..88618a2 100644 --- a/software/scheme.page +++ b/software/scheme.page @@ -36,9 +36,9 @@ SIOD Coding in ``edwin`` ----------------------- -..note: this section should be spun off as emacs. edwin is essentially a +*Note: this section should be spun off as emacs. edwin is essentially a scheme version of emacs. See this - `emacs cheatsheet `__ + `emacs cheatsheet `__* Common keyboard commands (usually 'M' is alt button, 'C' is ctrl, and 'S' is meta/super/"windows"): diff --git a/software/server-setup.page b/software/server-setup.page index 1ef884b..b364f7a 100644 --- a/software/server-setup.page +++ b/software/server-setup.page @@ -26,7 +26,7 @@ temboz ---------- The temboz feed reader is started by:: -$./temboz --server & + $ ./temboz --server & in the appropriate directory. diff --git a/software/unix-tricks.page b/software/unix-tricks.page index e1366dc..533a174 100644 --- a/software/unix-tricks.page +++ b/software/unix-tricks.page @@ -14,5 +14,5 @@ Fork many processes with `xargs` ----------------------------------- To fork off 10 instances of sleep with incremented lengths, 5 at a time:: -$ seq 10 20 | xargs -n 1 -P 5 sleep + $ seq 10 20 | xargs -n 1 -P 5 sleep diff --git a/tmp/Newcomb paradox.page b/tmp/Newcomb paradox.page deleted file mode 100644 index 58ace89..0000000 --- a/tmp/Newcomb paradox.page +++ /dev/null @@ -1,69 +0,0 @@ ---- -format: rst -toc: no -... -================== -Newcomb's Dialemma -================== - -Newcomb's paradox was thought up by a researcher named Newcomb; it was first -explored and written up by Robert Nozick in the 1969 paper -"Newcomb's Problem and Two principles of Choice". - -The Situation -------------- -As narrated by an all knowing "predictor":: - - I am going to give you a choice. It is important to know that I really - pretty much know what you are going to do. I have been watching their whole - life and am additionally an immortal being; i've been doing this a long - time and always guess correctly. It's also important to know that I am - unbiased and don't care which decision you make, I have nothing to gain - either way. - - Here are two boxes: a large and a small. The small has a 10 shekel coin - in it (show everybody). The large one may or may not have a thousand - shekels in it; you don't know. Your choice is to either take only the - large box or to take both the large and small boxes. The twist is that - I already knew which decision you will make and decided whether or not - to put the $1000 in the large box or not based on that knowledge. - If I knew you would "two box", then I left the large box empty. If I knew - you would "one box" then I filled it. - -Dominance Mindset ------------------ -Regardless of what decision was made previously, and whether or not there -is anything in the large box, the person is better off taking both boxes; -either they will get just $10 (better than none) or $1010 (better -than $1000). So two-box. - -Trusting Mindset ----------------- -The predictor is pretty much always right so we can just ignore the -possibility that they are wrong. In this case, choosing to one-box -implies that the Predictor knew you would and you get $1000; -choosing to two-box implies that the predictor knew you would and you -only get $10. - -The predictor doesn't even have to be perfectly accurate; say they are -90%: -If you one-box, your expected value is $900. -If you two-box, your expected value is $110. - -Discussion ----------- -It's disputed whether this is a paradox, and there are many deeper arguments -that I don't have time to go into here. Ultimately, I am a one-boxer -though this is something of a minority position. - -Afterword ---------- -The person who taught me this paradox, Professor Augustin Rayo, a -two-boxer, then had this to add. He was talking with his one-boxing friend -and accused her of letting irrationality undermine her logic: she is so -optimistic that if a statement S is unprovable, but it would be nicer if S -was true than false, then she pretens that S is proven. So basically, even -though there is no rationalization, she will accept a statement "just -because it would be nice", and this isn't how logic works. To which she -replied "but wouldn't it be nice if it was?". - diff --git a/tmp/Saccade.page b/tmp/Saccade.page deleted file mode 100644 index 85693c6..0000000 --- a/tmp/Saccade.page +++ /dev/null @@ -1,7 +0,0 @@ -Saccade -------- - -Saccades are small movements of the eye which generate a delta in our stream -of vision. Similar to the phenomena of "only seeing movement". - -(based on Jeff Hawkin's book "On Intelligence") diff --git a/tmp/Teaching CS.page b/tmp/Teaching CS.page deleted file mode 100644 index d441985..0000000 --- a/tmp/Teaching CS.page +++ /dev/null @@ -1,102 +0,0 @@ ---- -format: rst -categories: cs -toc: no -... -==================================== -Notes on Teaching Computer Science -==================================== - -:author: Bryan Newbold - -.. note:: Incomplete, just a structure of starting topics - -.. contents:: - -In thinking about how to teach somebody new "how to program" or "about -computers", it seems like getting the rough big picture is the best first step. - - -Engineering and Scientific Philosophies ------------------------------------------ -keywords: computation, computability, hierarchy, interface, implementation - -In approaching computer science it is important to note an arbitrary division -of the field between "computation" and "computability" that has arisen over -the years. Similar to the "theory" vs "experiment" schisms in other scientific -fields like physics, "computation" puts emphasis on actually generating -hardware and software to run in the real world, while "computability" focuses -on what can be computed and generalizations of specific computations. Of course -they are two sides of the same coin and should be appreciated together. - -It is almost impossible to deal with computer systems (hardware or software) -without breaking them up into modules and layers. Perhaps more so than in any -other field, conceptual barriers are reflected in the actual design and -implementation of systems, which can make it hard to learn how things work -because their inner workings are shielded from view both literally and -figuratively. For example, a software developer writing a web browser doesn't -have to know about what kind of monitor the user is sitting in front of, -what kind of physical link to the internet they have (or even how this -connection is managed), the details of their computer architecture, how their -application is delegated computing resources, what kind of mouse is being used, -etc etc. - -A more formal example is the ethernet protocol, which is used to -pass data between nodes in a relatively unstructured network. The ethernet -protocol itself lies above the physical "link layer", which means the same -protocol can be used for wireless radio communications or with conducting -wires. It lies below any sort of higher network layers and far below the -"application layer", so large amounts of data can be streamed over it between -two nodes, or messages between dozens of nodes can be passed over it, or it -can be only one link in a very large web of interconnections. This flexibility -has made it ubiquitous and is the protocol most network devices use without -a hitch, but occasionally it's imperfections can lead to problems at higher -levels which are hard to track down. - -Turing Completeness ------------------------------------------ -keywords: finite state machine, deterministic - -Personal Computer Hierarchy ------------------------------------------ -keywords: CPU, RAM, hard disk, peripherals, network, BIOS, motherboard, - operating system, serial, parallel, interrupts, multicore, register - -UNIX Operating Systems ------------------------------------------ -keywords: file system, kernel, driver, threading, - -UNIX is the Latin of operating systems: there were operating systems that came -after, and the average user isn't running a UNIX operating system, but it's -design is simple, functional, and has represents the dominant paradigms for -modern (non-experimental or special use) operating systems. - -As some context, Microsoft Windows is not directly based on UNIX. Apple OSX -and subsequent versions is built on top of a UNIX core. Linux is an open source -implementation of UNIX. BSD was the free UC Berkeley distribution of UNIX which -has branched off into open source implementations like FreeBSD, OpenBSD, and -NetBSD. "UNIX" got started as a Bell Labs research project in the 70's (?) - - -The Internet ------------------------------------------ -keywords: IP (internet protocol), ARP, MAC, routing, servers, backbone, - protocol, email, http, html - - -Software Development Tools ------------------------------------------ -keywords: compiler, lexical analysis, library, language, interpreter - - -Data Formats, Structures, and Algorithms ------------------------------------------ -keywords: string, integer, bit, list, pointer, tree, sort, P/NP - - -Design Paradigms ------------------------------------------ -keywords: server/client, object oriented, wrappers, KISS, parallelization, - resource locking, serialization, buffer - - diff --git a/tmp/Topics of Curiosity.page b/tmp/Topics of Curiosity.page deleted file mode 100644 index c07b13c..0000000 --- a/tmp/Topics of Curiosity.page +++ /dev/null @@ -1,54 +0,0 @@ ---- -format: rst -toc: no -... - -Topics of Curiosity ---------------------- - -*or, list of future knowledge items* - -* United Nations -* List of International Treaties - - including signatories - -* Ethernet -* Benthic Biology -* Antarctica -* Kyoto Protocol -* Sensory Deprivation -* Beat Authors -* Harvey Mudd -* National Science Foundation - - And other US national science organizations - -* Iraq War - - Strategy, costs, political figures, history, technology, prospects, companies, etc. - -* Recycling -* Pollution sources in the United States -* US Education System -* US Judicial Branch -* Kennedy School of Government -* Democratic Party -* Republican Party -* Green Party -* Bob Dole -* Al Gore -* Obama -* Book Publishing -* Internet - - Power consumption, user numbers, global connectivity, core and backbone services - -* One Laptop Per Child - - Bundled knowledge, regions, implementation plans, new software concepts, connectivity - -* Paul Dirac -* LaTeX -* vim -* pykrete diff --git a/tmp/newcomb-paradox.page b/tmp/newcomb-paradox.page new file mode 100644 index 0000000..58ace89 --- /dev/null +++ b/tmp/newcomb-paradox.page @@ -0,0 +1,69 @@ +--- +format: rst +toc: no +... +================== +Newcomb's Dialemma +================== + +Newcomb's paradox was thought up by a researcher named Newcomb; it was first +explored and written up by Robert Nozick in the 1969 paper +"Newcomb's Problem and Two principles of Choice". + +The Situation +------------- +As narrated by an all knowing "predictor":: + + I am going to give you a choice. It is important to know that I really + pretty much know what you are going to do. I have been watching their whole + life and am additionally an immortal being; i've been doing this a long + time and always guess correctly. It's also important to know that I am + unbiased and don't care which decision you make, I have nothing to gain + either way. + + Here are two boxes: a large and a small. The small has a 10 shekel coin + in it (show everybody). The large one may or may not have a thousand + shekels in it; you don't know. Your choice is to either take only the + large box or to take both the large and small boxes. The twist is that + I already knew which decision you will make and decided whether or not + to put the $1000 in the large box or not based on that knowledge. + If I knew you would "two box", then I left the large box empty. If I knew + you would "one box" then I filled it. + +Dominance Mindset +----------------- +Regardless of what decision was made previously, and whether or not there +is anything in the large box, the person is better off taking both boxes; +either they will get just $10 (better than none) or $1010 (better +than $1000). So two-box. + +Trusting Mindset +---------------- +The predictor is pretty much always right so we can just ignore the +possibility that they are wrong. In this case, choosing to one-box +implies that the Predictor knew you would and you get $1000; +choosing to two-box implies that the predictor knew you would and you +only get $10. + +The predictor doesn't even have to be perfectly accurate; say they are +90%: +If you one-box, your expected value is $900. +If you two-box, your expected value is $110. + +Discussion +---------- +It's disputed whether this is a paradox, and there are many deeper arguments +that I don't have time to go into here. Ultimately, I am a one-boxer +though this is something of a minority position. + +Afterword +--------- +The person who taught me this paradox, Professor Augustin Rayo, a +two-boxer, then had this to add. He was talking with his one-boxing friend +and accused her of letting irrationality undermine her logic: she is so +optimistic that if a statement S is unprovable, but it would be nicer if S +was true than false, then she pretens that S is proven. So basically, even +though there is no rationalization, she will accept a statement "just +because it would be nice", and this isn't how logic works. To which she +replied "but wouldn't it be nice if it was?". + diff --git a/tmp/teaching-cs.page b/tmp/teaching-cs.page new file mode 100644 index 0000000..d441985 --- /dev/null +++ b/tmp/teaching-cs.page @@ -0,0 +1,102 @@ +--- +format: rst +categories: cs +toc: no +... +==================================== +Notes on Teaching Computer Science +==================================== + +:author: Bryan Newbold + +.. note:: Incomplete, just a structure of starting topics + +.. contents:: + +In thinking about how to teach somebody new "how to program" or "about +computers", it seems like getting the rough big picture is the best first step. + + +Engineering and Scientific Philosophies +----------------------------------------- +keywords: computation, computability, hierarchy, interface, implementation + +In approaching computer science it is important to note an arbitrary division +of the field between "computation" and "computability" that has arisen over +the years. Similar to the "theory" vs "experiment" schisms in other scientific +fields like physics, "computation" puts emphasis on actually generating +hardware and software to run in the real world, while "computability" focuses +on what can be computed and generalizations of specific computations. Of course +they are two sides of the same coin and should be appreciated together. + +It is almost impossible to deal with computer systems (hardware or software) +without breaking them up into modules and layers. Perhaps more so than in any +other field, conceptual barriers are reflected in the actual design and +implementation of systems, which can make it hard to learn how things work +because their inner workings are shielded from view both literally and +figuratively. For example, a software developer writing a web browser doesn't +have to know about what kind of monitor the user is sitting in front of, +what kind of physical link to the internet they have (or even how this +connection is managed), the details of their computer architecture, how their +application is delegated computing resources, what kind of mouse is being used, +etc etc. + +A more formal example is the ethernet protocol, which is used to +pass data between nodes in a relatively unstructured network. The ethernet +protocol itself lies above the physical "link layer", which means the same +protocol can be used for wireless radio communications or with conducting +wires. It lies below any sort of higher network layers and far below the +"application layer", so large amounts of data can be streamed over it between +two nodes, or messages between dozens of nodes can be passed over it, or it +can be only one link in a very large web of interconnections. This flexibility +has made it ubiquitous and is the protocol most network devices use without +a hitch, but occasionally it's imperfections can lead to problems at higher +levels which are hard to track down. + +Turing Completeness +----------------------------------------- +keywords: finite state machine, deterministic + +Personal Computer Hierarchy +----------------------------------------- +keywords: CPU, RAM, hard disk, peripherals, network, BIOS, motherboard, + operating system, serial, parallel, interrupts, multicore, register + +UNIX Operating Systems +----------------------------------------- +keywords: file system, kernel, driver, threading, + +UNIX is the Latin of operating systems: there were operating systems that came +after, and the average user isn't running a UNIX operating system, but it's +design is simple, functional, and has represents the dominant paradigms for +modern (non-experimental or special use) operating systems. + +As some context, Microsoft Windows is not directly based on UNIX. Apple OSX +and subsequent versions is built on top of a UNIX core. Linux is an open source +implementation of UNIX. BSD was the free UC Berkeley distribution of UNIX which +has branched off into open source implementations like FreeBSD, OpenBSD, and +NetBSD. "UNIX" got started as a Bell Labs research project in the 70's (?) + + +The Internet +----------------------------------------- +keywords: IP (internet protocol), ARP, MAC, routing, servers, backbone, + protocol, email, http, html + + +Software Development Tools +----------------------------------------- +keywords: compiler, lexical analysis, library, language, interpreter + + +Data Formats, Structures, and Algorithms +----------------------------------------- +keywords: string, integer, bit, list, pointer, tree, sort, P/NP + + +Design Paradigms +----------------------------------------- +keywords: server/client, object oriented, wrappers, KISS, parallelization, + resource locking, serialization, buffer + + diff --git a/tmp/topics-of-curiosity.page b/tmp/topics-of-curiosity.page new file mode 100644 index 0000000..c07b13c --- /dev/null +++ b/tmp/topics-of-curiosity.page @@ -0,0 +1,54 @@ +--- +format: rst +toc: no +... + +Topics of Curiosity +--------------------- + +*or, list of future knowledge items* + +* United Nations +* List of International Treaties + + including signatories + +* Ethernet +* Benthic Biology +* Antarctica +* Kyoto Protocol +* Sensory Deprivation +* Beat Authors +* Harvey Mudd +* National Science Foundation + + And other US national science organizations + +* Iraq War + + Strategy, costs, political figures, history, technology, prospects, companies, etc. + +* Recycling +* Pollution sources in the United States +* US Education System +* US Judicial Branch +* Kennedy School of Government +* Democratic Party +* Republican Party +* Green Party +* Bob Dole +* Al Gore +* Obama +* Book Publishing +* Internet + + Power consumption, user numbers, global connectivity, core and backbone services + +* One Laptop Per Child + + Bundled knowledge, regions, implementation plans, new software concepts, connectivity + +* Paul Dirac +* LaTeX +* vim +* pykrete -- cgit v1.2.3