Sun Jul 21 01:19:01 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-05-01

HANGOUT

2024-07-21 | 2024-06-21 | 2024-05-21 | 2024-04-21 | 2024-03-21 | 2024-02-21 | 2024-01-21 | 2023-12-21 | 2023-11-21 | 2023-10-21 | 2023-09-21 | 2023-08-21 | 2023-07-21 | 2023-06-21 | 2023-05-21 | 2023-04-21 | 2023-03-21 | 2023-02-21 | 2023-01-21 | 2022-12-21 | 2022-11-21 | 2022-10-21 | 2022-09-21 | 2022-08-21 | 2022-07-21 | 2022-06-21 | 2022-05-21 | 2022-04-21 | 2022-03-21 | 2022-02-21 | 2022-01-21 | 2021-12-21 | 2021-11-21 | 2021-10-21 | 2021-09-21 | 2021-08-21 | 2021-07-21 | 2021-06-21 | 2021-05-21 | 2021-04-21 | 2021-03-21 | 2021-02-21 | 2021-01-21 | 2020-12-21 | 2020-11-21 | 2020-10-21 | 2020-09-21 | 2020-08-21 | 2020-07-21 | 2020-06-21 | 2020-05-21 | 2020-04-21 | 2020-03-21 | 2020-02-21 | 2020-01-21 | 2019-12-21 | 2019-11-21 | 2019-10-21 | 2019-09-21 | 2019-08-21 | 2019-07-21 | 2019-06-21 | 2019-05-21 | 2019-04-21 | 2019-03-21 | 2019-02-21 | 2019-01-21 | 2018-12-21 | 2018-11-21 | 2018-10-21 | 2018-09-21 | 2018-08-21 | 2018-07-21 | 2018-06-21 | 2018-05-21 | 2018-04-21 | 2018-03-21 | 2018-02-21 | 2018-01-21 | 2017-12-21 | 2017-11-21 | 2017-10-21 | 2017-09-21 | 2017-08-21 | 2017-07-21 | 2017-06-21 | 2017-05-21 | 2017-04-21 | 2017-03-21 | 2017-02-21 | 2017-01-21 | 2016-12-21 | 2016-11-21 | 2016-10-21 | 2016-09-21 | 2016-08-21 | 2016-07-21 | 2016-06-21 | 2016-05-21 | 2016-04-21 | 2016-03-21 | 2016-02-21 | 2016-01-21 | 2015-12-21 | 2015-11-21 | 2015-10-21 | 2015-09-21 | 2015-08-21 | 2015-07-21 | 2015-06-21 | 2015-05-21 | 2015-04-21 | 2015-03-21 | 2015-02-21 | 2015-01-21 | 2014-12-21 | 2014-11-21 | 2014-10-21 | 2014-09-21 | 2014-08-21 | 2014-07-21 | 2014-06-21 | 2014-05-21 | 2014-04-21 | 2014-03-21 | 2014-02-21 | 2014-01-21 | 2013-12-21 | 2013-11-21 | 2013-10-21 | 2013-09-21 | 2013-08-21 | 2013-07-21 | 2013-06-21 | 2013-05-21 | 2013-04-21 | 2013-03-21 | 2013-02-21 | 2013-01-21 | 2012-12-21 | 2012-11-21 | 2012-10-21 | 2012-09-21 | 2012-08-21 | 2012-07-21 | 2012-06-21 | 2012-05-21 | 2012-04-21 | 2012-03-21 | 2012-02-21 | 2012-01-21 | 2011-12-21 | 2011-11-21 | 2011-10-21 | 2011-09-21 | 2011-08-21 | 2011-07-21 | 2011-06-21 | 2011-05-21 | 2011-04-21 | 2011-03-21 | 2011-02-21 | 2011-01-21 | 2010-12-21 | 2010-11-21 | 2010-10-21 | 2010-09-21 | 2010-08-21 | 2010-07-21 | 2010-06-21 | 2010-05-21 | 2010-04-21 | 2010-03-21 | 2010-02-21 | 2010-01-21 | 2009-12-21 | 2009-11-21 | 2009-10-21 | 2009-09-21 | 2009-08-21 | 2009-07-21 | 2009-06-21 | 2009-05-21 | 2009-04-21 | 2009-03-21 | 2009-02-21 | 2009-01-21 | 2008-12-21 | 2008-11-21 | 2008-10-21 | 2008-09-21 | 2008-08-21 | 2008-07-21 | 2008-06-21 | 2008-05-21 | 2008-04-21 | 2008-03-21 | 2008-02-21 | 2008-01-21 | 2007-12-21 | 2007-11-21 | 2007-10-21 | 2007-09-21 | 2007-08-21 | 2007-07-21 | 2007-06-21 | 2007-05-21 | 2007-04-21 | 2007-03-21 | 2007-02-21 | 2007-01-21 | 2006-12-21 | 2006-11-21 | 2006-10-21 | 2006-09-21 | 2006-08-21 | 2006-07-21 | 2006-06-21 | 2006-05-21 | 2006-04-21 | 2006-03-21 | 2006-02-21 | 2006-01-21 | 2005-12-21 | 2005-11-21 | 2005-10-21 | 2005-09-21 | 2005-08-21 | 2005-07-21 | 2005-06-21 | 2005-05-21 | 2005-04-21 | 2005-03-21 | 2005-02-21 | 2005-01-21 | 2004-12-21 | 2004-11-21 | 2004-10-21 | 2004-09-21 | 2004-08-21 | 2004-07-21 | 2004-06-21 | 2004-05-21 | 2004-04-21 | 2004-03-21 | 2004-02-21 | 2004-01-21 | 2003-12-21 | 2003-11-21 | 2003-10-21 | 2003-09-21 | 2003-08-21 | 2003-07-21 | 2003-06-21 | 2003-05-21 | 2003-04-21 | 2003-03-21 | 2003-02-21 | 2003-01-21 | 2002-12-21 | 2002-11-21 | 2002-10-21 | 2002-09-21 | 2002-08-21 | 2002-07-21 | 2002-06-21 | 2002-05-21 | 2002-04-21 | 2002-03-21 | 2002-02-21 | 2002-01-21 | 2001-12-21 | 2001-11-21 | 2001-10-21 | 2001-09-21 | 2001-08-21 | 2001-07-21 | 2001-06-21 | 2001-05-21 | 2001-04-21 | 2001-03-21 | 2001-02-21 | 2001-01-21 | 2000-12-21 | 2000-11-21 | 2000-10-21 | 2000-09-21 | 2000-08-21 | 2000-07-21 | 2000-06-21 | 2000-05-21 | 2000-04-21 | 2000-03-21 | 2000-02-21 | 2000-01-21 | 1999-12-21

Key: Value:

Key: Value:

MESSAGE
DATE 2015-05-02
FROM Ruben Safir
SUBJECT Subject: [NYLXS - HANGOUT] Great Article on Software Concordance program writing

http://www.linuxjournal.com/article/5833


just the first page


Kernel Locking Techniques

Issue 100

From Issue #100
August 2002

Aug 01, 2002 By Robert Love
in

* SysAdmin

Robert explains the various locking primitives in the Linux kernel, why
you need them and how kernel developers can use them to write safe code.

Proper locking can be tough—real tough. Improper locking can result in
random crashes and other oddities. Poorly designed locking can result in
code that is hard to read, performs poorly and makes your fellow kernel
developers cringe. In this article, I explain why kernel code requires
locking, provide general rules for proper kernel locking semantics and
then outline the various locking primitives in the Linux kernel.

Why Do We Need Locking in the Kernel?

The fundamental issue surrounding locking is the need to provide
synchronization in certain code paths in the kernel. These code paths,
called critical sections, require some combination of concurrency or
re-entrancy protection and proper ordering with respect to other events.
The typical result without proper locking is called a race condition.
Realize how even a simple i++ is dangerous if i is shared! Consider the
case where one processor reads i, then another, then they both increment
it, then they both write i back to memory. If i were originally 2, it
should now be 4, but in fact it would be 3!

This is not to say that the only locking issues arise from SMP
(symmetric multiprocessing). Interrupt handlers create locking issues,
as does the new preemptible kernel, and any code can block (go to
sleep). Of these, only SMP is considered true concurrency, i.e., only
with SMP can two things actually occur at the exact same time. The other
situations—interrupt handlers, preempt-kernel and blocking
methods—provide pseudo concurrency as code is not actually executed
concurrently, but separate code can mangle one another's data.

These critical regions require locking. The Linux kernel provides a
family of locking primitives that developers can use to write safe and
efficient code.

SMP Locks in a Uniprocessor Kernel

Whether or not you have an SMP machine, people who use your code may.
Further, code that does not handle locking issues properly is typically
not accepted into the Linux kernel. Finally, with a preemptible kernel
even UP (uniprocessor) systems require proper locking. Thus, do not
forget: you must implement locking.

Thankfully, Linus made the excellent design decision of keeping SMP and
UP kernels distinct. This allows certain locks not to exist at all in a
UP kernel. Different combinations of CONFIG_SMP and CONFIG_PREEMPT
compile in varying lock support. It does not matter, however, to the
developer: lock everything appropriately and all situations will be covered.

Atomic Operators

We cover atomic operators initially for two reasons. First, they are the
simplest of the approaches to kernel synchronization and thus the
easiest to understand and use. Second, the complex locking primitives
are built off them. In this sense, they are the building blocks of the
kernel's locks. Atomic operators are operations, like add and subtract,
which perform in one uninterruptible operation. Consider the previous
example of i++. If we could read i, increment it and write it back to
memory in one uninterruptible operation, the race condition discussed
above would not be an issue. Atomic operators provide these
uninterruptible operations. Two types exist: methods that operate on
integers and methods that operate on bits. The integer operations work
like this:

atomic_t v;
atomic_set(&v, 5); /* v = 5 (atomically) */
atomic_add(3, &v); /* v = v + 3 (atomically) */
atomic_dec(&v); /* v = v - 1 (atomically) */
printf("This will print 7: %d\n", atomic_read(&v));

They are simple. There are, however, little caveats to keep in mind when
using atomics. First, you obviously cannot pass an atomic_t to anything
but one of the atomic operators. Likewise, you cannot pass anything to
an atomic operator except an atomic_t. Finally, because of the
limitations of some architectures, do not expect atomic_t to have more
than 24 usable bits. See the “Function Reference” Sidebar for a list of
all atomic integer operations.

Function Reference


The next group of atomic methods is those that operate on individual
bits. They are simpler than the integer methods because they work on the
standard C data types. For example, consider void set_bit(int nr, void
*addr). This function will atomically set to 1 the “nr-th” bit of the
data pointed to by addr. The atomic bit operators are also listed in the
“Function Reference” Sidebar.

Spinlocks

For anything more complicated than trivial examples like those above, a
more complete locking solution is needed. The most common locking
primitive in the kernel is the spinlock, defined in
include/asm/spinlock.h and include/linux/spinlock.h. The spinlock is a
very simple single-holder lock. If a process attempts to acquire a
spinlock and it is unavailable, the process will keep trying (spinning)
until it can acquire the lock. This simplicity creates a small and fast
lock. The basic use of the spinlock is:

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
spin_lock_irqsave(&mr_lock, flags);
/* critical section ... */
spin_unlock_irqrestore(&mr_lock, flags);

The use of spin_lock_irqsave() will disable interrupts locally and
provide the spinlock on SMP. This covers both interrupt and SMP
concurrency issues. With a call to spin_unlock_irqrestore(), interrupts
are restored to the state when the lock was acquired. With a UP kernel,
the above code compiles to the same as:

unsigned long flags;
save_flags(flags);
cli();
/* critical section ... */
restore_flags(flags);

which will provide the needed interrupt concurrency protection without
unneeded SMP protection. Another variant of the spinlock is
spin_lock_irq(). This variant disables and re-enables interrupts
unconditionally, in the same manner as cli() and sti(). For example:

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED;
spin_lock_irq(&mr_lock);
/* critical section ... */
spin_unlock_irq(&mr_lock);

This code is only safe when you know that interrupts were not already
disabled before the acquisition of the lock. As the kernel grows in size
and kernel code paths become increasingly hard to predict, it is
suggested you not use this version unless you really know what you are
doing.

All of the above spinlocks assume the data you are protecting is
accessed in both interrupt handlers and normal kernel code. If you know
your data is unique to user-context kernel code (e.g., a system call),
you can use the basic spin_lock() and spin_unlock() methods that acquire
and release the specified lock without any interaction with interrupts.

A final variation of the spinlock is spin_lock_bh() that implements the
standard spinlock as well as disables softirqs. This is needed when you
have code outside a softirq that is also used inside a softirq. The
corresponding unlock function is naturally spin_unlock_bh().

Note that spinlocks in Linux are not recursive as they may be in other
operating systems. Most consider this a sane design decision as
recursive spinlocks encourage poor code. This does imply, however, that
you must be careful not to re-acquire a spinlock you already hold, or
you will deadlock.

Spinlocks should be used to lock data in situations where the lock is
not held for a long time—recall that a waiting process will spin, doing
nothing, waiting for the lock. (See the “Rules” Sidebar for guidelines
on what is considered a long time.) Thankfully, spinlocks can be used
anywhere. You cannot, however, do anything that will sleep while holding
a spinlock. For example, never call any function that touches user
memory, kmalloc() with the GFP_KERNEL flag, any semaphore functions or
any of the schedule functions while holding a spinlock. You have been
warned.

If you need a lock that is safe to hold for longer periods of time, safe
to sleep with or capable of allowing concurrency to do more than one
process at a time, Linux provides the semaphore.


  1. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Great Article on Software Concordance program writing
  2. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Excellent article on Virtual Paging and OS memory
  3. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Semephores and what the heck are those things?
  4. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] digital advert fraud
  5. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Go Language tutorials
  6. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Journal Club meeting
  7. 2015-05-03 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  8. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  9. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Journal Article
  10. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  11. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  12. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  13. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  14. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  15. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  16. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie of the week
  17. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  18. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  19. 2015-05-04 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  20. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  21. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: a second look at storage and pointer fundamentals
  22. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Kernel Scheduling and wait queues
  23. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #197 - YAPC::EU Master classes - talks - hackathons
  24. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [ Khal Tiferes Yaakov ] Lag B'Omer in Passaic
  25. 2015-05-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Nice possible project for NYLXS or others
  26. 2015-05-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You're hosting "Journal Club Meetings"
  27. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Things to study over the summer
  28. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Things to study over the summer
  29. 2015-05-08 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Things to study over the summer
  30. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: Kernel Scheduler and wiat queues
  31. 2015-05-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movies of the Week
  32. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] scheduler Slides
  33. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  34. 2015-05-11 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  35. 2015-05-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  36. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] jobs
  37. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Job sound like this evenings lectures
  38. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] LAMP Jobs
  39. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] April Journal is Available
  40. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You and 256 others are going to "Btrfs"
  41. 2015-05-13 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [member-at-linkedin.com: RE: April Journal is Available]
  42. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [mrbrklyn-at-panix.com: Re: [NYLXS - HANGOUT] Things to study over the
  43. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Malloc systemtap probes: an example
  44. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Stackiq - Educational Program
  45. 2015-05-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weekly Education Meeting
  46. 2015-05-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] ssh hack
  47. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [manjaro-general] Manjaro 0.8.13-rc1 released
  48. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #199 - Rust 1.0 is out!
  49. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Check This Out
  50. 2015-05-18 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Check This Out
  51. 2015-05-18 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Check This Out
  52. 2015-05-18 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [jkeen-at-verizon.net: ny.pm Technical Meeting Wed May 20 6:15 pm]
  53. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  54. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] copyright vrs free speach on utube
  55. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  56. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  57. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weapons of Mass Destruction my ass
  58. 2015-05-19 Robert Menes <viewtiful.icchan-at-gmail.com> Re: [NYLXS - HANGOUT] Check This Out
  59. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] NYLXS
  60. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  61. 2015-05-20 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  62. 2015-05-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Free Software Business
  63. 2015-05-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Summer NYLXS Study Schedule
  64. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] C++ maheim
  65. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: IEEE NY Meeting Announcement
  66. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Plane Hacking
  67. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Oracle attach on Android Copyright
  68. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] adblock is legal... who knew?
  69. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] Steeley Dan in NYC
  70. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: privacy and data security
  71. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  72. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  73. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [ruben-at-www.mrbrklyn.com: Linux 1 Book]
  74. 2015-05-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Minting Money with Free software
  75. 2015-05-31 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] anyone familiar with STM?

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!