Ryan Curtin’s Presentation from November 30th, 2017
Everybody knows about the open-source world. You do too, because
you’re reading this email. But more often than not, it’s difficult to
jump in. Lots of projects are huge and the barrier to entry is high.
Some small projects don’t have anything easy to do, and other projects
are inaccessible. In this presentation, I’ll describe ways to get
involved in open source for all levels of technical ability; this will
include a discussion of Github, mailing lists, Sourceforge, Trac,
Bugzilla, and the other tools projects use to organize themselves. I’ll
also discuss the Google Summer of Code program, which I’ve been a part
of for five years now. All in all, it’s not hard to get involved!
Slides from Ryan Curtin’s Presentation Tonight:
Download (PDF, 273.98KB)
Pdf’s from Addison’s Presentation:
Download (PDF, 68.52KB)
Download (PDF, 49.75KB)
Ryan will be giving a presentation on CMake.
Maybe you’ve heard of CMake before. If you haven’t, maybe you’ve
heard of autotools. And if you have worked with autotools, well, I am
sure your friends have heard your sighs of sorrow. If you have worked
with CMake, you probably have your own sighs of sorrow too. Build
systems, or “makefile generators”, as CMake calls itself, are never
pretty. But it’s better than that festering mess you call a Makefile.
I mean come on! You don’t even know how it works anymore. Nobody does.
It’s this horrifying black box that executables magically come out of.
Oh, and it’s not portable… don’t even think about running that on
HP-UX or whatever. And if it is portable… well, I can only imagine
the nightmare that Makefile must be.
CMake provides most of a solution to your building and compilation
problems. It has a nice language which lets you define how to build
your projects, and on top of that, it’s portable, even to Windows.
Unfortunately, there is some voodoo required when dealing with CMake.
My aim in this presentation is to shed light on some of this voodoo and
give you enough knowledge to (a) start building your simple (or
advanced) projects with CMake and (b) know how to find solutions to your
more complex problems (and unfortunately with CMake, Google-fu isn’t
Hope to see you there!
The slides from Josh’s presentation on RAID and LVM.
Download (PDF, 60.83KB)
Our next meeting will be this Wednesday September 3 at 7:30 pm in 53 CCB. Brian Lasseter a former LUG president will be coming to speak to us. Here is some information about him and his talk Wednesday night:
Brian Lasseter is an ex-president, and ex-founder of LUG@GT who graduated in 2001. He is in town to do some recruiting for IBM, but tonight he is visiting LUG@GT on his own as a LUG@GT alumni to discuss chip design, using Linux to verify hardware function, and the importance of Linux in the workplace.
Brian Lasseter has a decade of experience as an engineer focusing on physical design synthesis and static timing analysis of IBM’s latest generation of P and Z series mainframe CPUs. When you are on the cutting edge, there are many things to watch out for, and Linux is the workhorse that runs our chip design tools, and verifies hardware that comes back from the Fab. There will be 300mm silicon wafers and example hardware at the meeting.
We will be meeting at 7:00 this Wednesday in CCB 52. We will discuss plans for the semester. Ryan Curtin will be giving a presentation starting at 7:30 on “Why Open Source is Better”. If you interested in learning Linux or asking Linux questions, this first meeting is a great way to introduce yourself to the group.
We are currently planning an Installfest / Android rooting event this Fall. It will be either late September or early October. Check back here for more details.
SDL, the Simple Directmedia Layer, provides the foundation for writing games
(and more!) on a variety of platforms, including Linux, Windows, OS X, iOS,
and Android. We’ll explore what the new 2.0 release brings to developers:
new features, new support for modern devices, and cleaner APIs.
System logs are great; you can see exactly what’s happened or what’s
happening on your system. The problem arises once you step up to more
than a handful of systems. The massive mass of massively massive log
files is simply too much for grep and/or your sanity to handle. This is
were Logstash comes in. In a nutshell Logstash allows any number of a
variety of inputs to then be modified to the user’s preferences (uniform
time-stamps for example) and then shipped out to plethora of outputs.
One of these outputs is ElasticSearch which indexes all of the entries
and makes them instantly searchable (All through a snazzy ui which will
also be covered)