Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shahar Dag]

Hi

If it is going to be a lecture about several implementation of source 
control, I can open a demo svn repository in SSDL

Shahar Dag
System & Software Development Laboratory (SSDL)
Computer Science Department
Technion - Israel Institute of Technology
Haifa, Israel
Tel. 972-4-829-4880
Fax 972-4-829-4878

- Original Message - 
From: "Orna Agmon Ben-Yehuda" 
To: 
Cc: "Haifa Linux Club" 
Sent: Thursday, October 15, 2009 8:17 PM
Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"


> Great idea. Can you do this? We have not had anything on source
> control since Tzahi Fadida's CVS.
>
> Tzafrir - Development tools will be given, covering such topics.
>
> On Thu, Oct 15, 2009 at 5:14 PM, boazg  wrote:
>> as a side note, a seperate lecture on git for CS students, and how to use 
>> it
>> with t2 would be a good idea.
>>
>> On Thu, Oct 15, 2009 at 16:44, Eli Billauer  wrote:
>>>
>>> Hello again.
>>>
>>> The FOSS lecture will be held by Orr (I have to admit I wasn't aware
>>> that he's a candidate). There were several other eligible lecturers who
>>> came forward, but being the club's founder, Orr has a somewhat natural
>>> advantage (on top of his well-known preaching skills). ;)
>>>
>>> Shahar Dag (the SSDL lab's engineer and a Haifux member) will take the
>>> Configuration party from here. Please coordinate your activities with
>>> him. Those of you who have already volunteered for this, will be
>>> contacted by Shahar soon. Since there's much logistics in an event like
>>> this, I believe it's best headed by the one who runs the location.
>>>
>>> Thank you all for the good spirit. Let's keep it up this way!
>>>
>>> Eli
>>>
>>>
>>>
>>>
>>> --
>>> Web: http://www.billauer.co.il
>>>
>>> ___
>>> Haifux mailing list
>>> Haifux@haifux.org
>>> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>>
>>
>>
>> --
>>
>> Stephen Leacock - "I detest life-insurance agents: they always argue that 
>> I
>> shall some day die, which is not so."
>> ___
>> Haifux mailing list
>> Haifux@haifux.org
>> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>>
>>
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
> 

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[guy keren]

(if you top-post - i'll post-top too! :P~~~)

well, that _is_ good news for employers (bad news for the students ;)

--guy

Vadim Eisenberg wrote:
> guy keren wrote:
>> you can mention memory leaks if you want - but students don't care about 
>> them so much, because it doesn't break their programs.
> 
> Starting from the Winter 2008-2009 semester, the memory leaks are checked in 
> Matam (Introduction to Systems Programming) course and 1 point is reduced for 
> each leak. The check is done automatically, using, guess what, valgrind. So 
> the students in Matam actually care very much about the memory leaks.
> 
> Vadim
> 
> -Original Message-
> From: haifux-boun...@haifux.org [mailto:haifux-boun...@haifux.org] On Behalf 
> Of guy keren
> Sent: Friday, October 16, 2009 9:47 AM
> To: Eli Billauer
> Cc: Haifa Linux Club
> Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"
> 
> Eli Billauer wrote:
>> guy keren wrote:
>>
>>> what - no valgrind?
>>>
>> I stand corrected. A quick demonstration of valgrind (show how it 
>> detects memory leaks and access to unallocated/uninitialized memory) 
>> is in place. It's definitely something handy for a student, and it's 
>> so simple to use.
>>
>>   Eli
>>
> 
> i think the best demo for valgrind would be:
> 
> 1. this step should be done at home: write a program that has a non-obvious 
> problem with corrupting its memory (make sure that when you run it, it 
> actually crashes)
> 
> 2. the next steps will be done during the demonstration: show it to the 
> people (the source, how the program crashes, and how you fail to find the 
> problem even when the crash is done inside gdb)
> 
> 3. show them how you find the bug within seconds using valgrind.
> 
> you can mention memory leaks if you want - but students don't care about them 
> so much, because it doesn't break their programs. they do care about memory 
> corruption if it indeed causes their program to crash.
> 
> --guy
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
> 

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shlomi Fish]

On Sunday 18 Oct 2009 11:49:36 boazg wrote:
> i don't think 20 minutes is enough for subversion if students are to use
> svn+ssh:// from t2. an hour is minimum. it should get it's own seperate
> lecture, IMHO. also, it shoudl be pitched seperately, as it has apeal also
> for students working on obscure OS's that arent POSIX-like. just another
> hook for FOSS.

‏Yes. Indeed, one of Subversion's main selling points is that it works fine on 
Microsoft Windows's Win32 (without the need for cygwin or any other funky 
stuff - though it works fine in cygwin too.). I recall a few years ago that a 
few Subversion developers worked on a Subversion port to IBM EBCDIC-based 
platforms, which don't even have ASCII and UTF-8, because there's some demand 
for it. Don't know how well Subversion runs on VMS, VxWorks, Windows CE, and 
other "weird" not-entirely-Unix OSes. 

> git, imho, for your averige MATAM student, would take much longer than that
> to learn, to the point where it's useful. once you understand SVN and have
> some experance, it's much simpler to learn git later down the line.
> 

You are right on the mark here. I think subversion (or possibly also hg) is a 
useful stepping stone to git, similar to the fact that I always recommend 
beginning programmers to start learning Perl/Python/Ruby/etc. before they 
learn C, because I knew that it really helped me to know GW-BASIC/QBasic/etc. 
before I learnt C, [BASIC] because by learning BASIC, I had a grasp on some of 
the basic (pardon the pun) elements of programming. And yes, I learned C, 
C/C++, as well as Perl, UNIX/Linux, some Win32 and MFC programming and bits of 
other stuff before I came to the Technion, and would recommend anyone to do so 
as early as possible.

Regards,

Shlomi Fish

[BASIC] - yes, I got it - I'm mutilated for life. Please stop parroting and 
misapplying Dijkstra's opinions from the 60's or earlier. Some old dogs cannot 
be taught new tricks. But all people are capable of growing with the right 
attitude and overcoming their old limitations (elephant tied to a rope in the 
circus and all as opposed to a human being and all). I hate fatalism with a 
passion.

> On Sun, Oct 18, 2009 at 08:51, Ohad Lutzky  wrote:
> > In the case that this is only a 20 minute lecture, I wholeheartedly
> > agree. I do think that git should be mentioned, in a one-liner, as "a
> > more advanced tool that also allows you to work offline".
> >
> > So, while I agree that git is too complicated to learn in 20 minutes
> > (takes 1-2 hours from my experience), it has a different upside when
> > compared to subversion: Administration is far easier. This is true for
> > any DVCVS, and stems from the fact that nobody needs write-access to
> > anything but his own files. Users will want to use whatever VCS is taught
> > in order to collaborate, and this requires some support work from the
> > admins, which should be taken into account. Either that or an alternative
> > free, easy-to-setup, fast and technion-accessible solution should be
> > shown.
> >
> > On Sun, Oct 18, 2009 at 8:37 AM, Shachar Shemesh 
wrote:
> >>  Ohad Lutzky wrote:
> >>
> >> Of course it would. But this one puts a lot of candy down that same path
> >> as well. These mines hurt, but are not fatal (again, from my experience,
> >> all mistakes can be recovered if detected within a reasonable time), and
> >> git's features make it, IMO, worth the trouble. For example, while many
> >> people find the staging area confusing (you have to "add" a file you've
> >> changed again in order to commit it, or just use commit -a to
> >> automatically add all changed files), it allows git to do awesome stuff
> >> like "git add -p"; this command goes over the differences from the
> >> previous version (like git diff), and asks you which hunks to stage.
> >> This means you can make a set of changes, realize it can be logically
> >> split into two, smaller sets of changes, and proceed to commit it as two
> >> sets of changes. Or, for a more common case, it allows you to stage only
> >> your actual fix to the commit without the various debugging statements
> >> you've added across your code in order to track down a bug, and do a
> >> quick "git reset --hard" afterwards.
> >>  There's a succinct list of reasons I like git here:
> >> http://whygitisbetterthanx.com/
> >>
> >>   I'm getting the sense that this conversation has gone off the main
> >> track a little. This is, I'll admit, also my fault. The question here is
> >> not "which VCS is better" (for which my answer, if you look at it, is
> >> "depends"), but "which VCS should we teach in the dev lecture of the W2L
> >> series".
> >>
> >> Here's the thing. When you first start to use a new system, what you see
> >> is mostly the mines. If this is the first system of its kind, you are
> >> likely to run into mines that are not really mines, but your
> >> misunderstanding of what the system is supposed to do, but still, the
> >> mines (real and conceptual) are m

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shlomi Fish]

Hi Oded!

Trimming your message.

On Sunday 18 Oct 2009 08:51:23 Ohad Lutzky wrote:
> In the case that this is only a 20 minute lecture, I wholeheartedly agree.
>  I do think that git should be mentioned, in a one-liner, as "a more
>  advanced tool that also allows you to work offline".
> 

Naturally, you should mention it for completeness sake. You should also 
mention bzr and Mercurial and/or refer people to http://better-scm.berlios.de/ 
or something similar [better-scm] for further reading, a comparison and 
discussion.

Here is what I think of the various prominent FOSS VCSes :

* Subversion (svn) - naturally, I may be biased towards it because I'm still 
using it for a lot (probably most) stuff, and have also contributed to it, a 
long time before git or hg existed (or even Bazaar and Bazaar NG which is now 
bzr), when its main competitors were Arch/larch/tla and Aegis and later darcs.  
See also:

http://onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html

( Monotone is still around and served as the main inspiration for git, but 
from my impression very few people use it. )

Subversion is very polished - it compiles and runs well on most (all?) modern 
UNIXes and many old ones, works very well on MS Windows (as a client and as a 
server), has an intuitive syntax and command output and mostly works as 
expected. Branching and merging there is much nicer than with CVS, at least in 
my opinion, though branches and tags are just free form directory copies - not 
"real" repository-wide tags and branches which git and hg support.

I can probably rant a lot about the unjustifiably poor perception of 
Subversion in the blogosphere that I read, where people often do a apples-to-
oranges comparison of it to something else. I have learnt git and hg and am 
still more than willing to use Subversion for some stuff due to its usability, 
portability and software engineering (having APIs, etc.) advantages, which I 
have called its "polish".

In any case, as Ben Collins-Sussman notes, while Subversion has proven popular 
in the open-source world to a large extent (though lately there was a trend to 
use VCSes such as hg, bzr, git, etc. instead), it has been extremely popular 
among the "80%" of software developers: various developers who are not working 
on shrinkwrap software (or alternatively shrinkwrap software that is niche but 
still profitable enough to make a living out of), and that are using it as a 
high-quality, cheap (gratis in fact) and open-source alternative to Microsoft 
Visual SourceSafe, CVS, Perforce, ClearCase, etc.:

http://blog.red-bean.com/sussman/?p=79

I know at least two people in Israel who give Subversion consulting, and often 
it just means they get a monthly or yearly consulting fee to agree to support 
Subversion in case there's a problem with it, which usually does not happen 
because it works very well, but is needed to settle the pointy-haired bosses 
(PHBs) who need commercial support. This is still probably cheaper for them 
than paying for a ClearCase licence, and naturally Visual SourceSafe, despite 
an innocent and easy appearance, is much more hazardous and time consuming in 
the long run (and obviously is not portable at all). 

OK. enough about svn.

* bzr - my main problem with it is that it is painfully slow. Many local bzr 
operations are slower than even the equivalent svn operations which finish 
pretty quickly here. While it may be another SNAFU on my relatively-old-and-
constantly-updated Mandriva Cooker system, which works pretty well and is 
fast, but sometimes acquires some weird problems, http://dazjorz.com/ have 
said that a local filesystem bzr was slower for him than svn in conjuction 
with Sourceforge, and he is using Debian I think.

Part of the problem seems to be that bzr is written in pure-Python, while hg 
which is also mostly Pythonic has parts written in ANSI C for speed.

In any case, this horrible performance makes bzr a non-starter for me. As 
patient as I can become, it is still too slow to be effective. Now the GNU 
project wants to convert the Emacs CVS repository (with a large codebase and 
years upon years of history) to bzr (which is not in the process of becoming a 
GNU project - possibly a typical GNU NIH), so hopefully this will motivate 
some work on optimising bzr and making it scale better.

* git - I've been using git in conjunction with github for a long time now. 
github is a very nice service (though I'm skeptical about its profitability), 
but git still leaves a lot to be desired. I still could not fully get to the 
bottom of the program model of git, and a lot of git usability and tricks 
stuff has been the topic of a lot of blog posts lately. I don't recall so many 
blog posts about Subversion when it started to become popular.

There are several possible explanations for this, but I tend to think part of 
the problem is that git has a more complex and counter-intuitive 
architecture[intuitive] and provides more fodder for blogg

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shahar Dag]

Dotan

Do you have solution to the Technion video problem?
If yes, I will be happy to implement it in SSDL & put it in our wiki

Shahar Dag
System & Software Development Laboratory (SSDL)
Computer Science Department
Technion - Israel Institute of Technology
Haifa, Israel
Tel. 972-4-829-4880
Fax 972-4-829-4878

- Original Message - 
From: "Dotan Cohen" 
To: 
Cc: "Haifa Linux Club" 
Sent: Thursday, October 15, 2009 9:06 PM
Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"


> 2009/10/15 boazg <>:
>> as a side note, a seperate lecture on git for CS students, and how to use 
>> it
>> with t2 would be a good idea.
>
> As a subside note, a separate lecture on getting the
> video.technion.ac.il site videos working in Linux would be great. VLC
> plays them, but not at 150% speed or other effects. This is rather
> important for video lectures.
>
> -- 
> Dotan Cohen
>
> http://what-is-what.com
> http://gibberish.co.il
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
> 

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[boazg]

i don't think 20 minutes is enough for subversion if students are to use
svn+ssh:// from t2. an hour is minimum. it should get it's own seperate
lecture, IMHO. also, it shoudl be pitched seperately, as it has apeal also
for students working on obscure OS's that arent POSIX-like. just another
hook for FOSS.
git, imho, for your averige MATAM student, would take much longer than that
to learn, to the point where it's useful. once you understand SVN and have
some experance, it's much simpler to learn git later down the line.

On Sun, Oct 18, 2009 at 08:51, Ohad Lutzky  wrote:

> In the case that this is only a 20 minute lecture, I wholeheartedly agree.
> I do think that git should be mentioned, in a one-liner, as "a more advanced
> tool that also allows you to work offline".
>
> So, while I agree that git is too complicated to learn in 20 minutes (takes
> 1-2 hours from my experience), it has a different upside when compared to
> subversion: Administration is far easier. This is true for any DVCVS, and
> stems from the fact that nobody needs write-access to anything but his own
> files. Users will want to use whatever VCS is taught in order to
> collaborate, and this requires some support work from the admins, which
> should be taken into account. Either that or an alternative free,
> easy-to-setup, fast and technion-accessible solution should be shown.
>
>
> On Sun, Oct 18, 2009 at 8:37 AM, Shachar Shemesh wrote:
>
>>  Ohad Lutzky wrote:
>>
>> Of course it would. But this one puts a lot of candy down that same path
>> as well. These mines hurt, but are not fatal (again, from my experience, all
>> mistakes can be recovered if detected within a reasonable time), and git's
>> features make it, IMO, worth the trouble. For example, while many people
>> find the staging area confusing (you have to "add" a file you've changed
>> again in order to commit it, or just use commit -a to automatically add all
>> changed files), it allows git to do awesome stuff like "git add -p"; this
>> command goes over the differences from the previous version (like git diff),
>> and asks you which hunks to stage. This means you can make a set of changes,
>> realize it can be logically split into two, smaller sets of changes, and
>> proceed to commit it as two sets of changes. Or, for a more common case, it
>> allows you to stage only your actual fix to the commit without the various
>> debugging statements you've added across your code in order to track down a
>> bug, and do a quick "git reset --hard" afterwards.
>>  There's a succinct list of reasons I like git here:
>> http://whygitisbetterthanx.com/
>>
>>   I'm getting the sense that this conversation has gone off the main
>> track a little. This is, I'll admit, also my fault. The question here is not
>> "which VCS is better" (for which my answer, if you look at it, is
>> "depends"), but "which VCS should we teach in the dev lecture of the W2L
>> series".
>>
>> Here's the thing. When you first start to use a new system, what you see
>> is mostly the mines. If this is the first system of its kind, you are likely
>> to run into mines that are not really mines, but your misunderstanding of
>> what the system is supposed to do, but still, the mines (real and
>> conceptual) are mostly what you see. You do not, typically, see the candies,
>> for the very simple reason that you do not understand the system well enough
>> to appreciate or make use of them.
>>
>> As you use of the system matures, you learn to change your thinking to not
>> regard some things as mines, and avoid the real ones. As that happens, the
>> mines become less and less important, and the candies become more and more
>> interesting. The main pre-requisite for that happening is that YOU HAVE NOT
>> GIVEN UP ON THE TOOL!
>>
>> This thread started around a very specific question - should Haifux teach
>> git, or some other version control system, as part of the development tools
>> lecture. Any answer should take into account that amount of time given for
>> this part of the lecture (between 10 and 20 minutes), and the amount of
>> tutoring the students will have down the road (none unless they seek it).
>> Under those conditions, in my opinion, git is the wrong tool because:
>>
>>- Anyone who has any experience with VCS will, likely, have used
>>server based ones. Git, for them, contains all of the misconception mines
>>that go with a distributed revision control
>>- Git has some actual bone-fide mines, lain on the path traversed even
>>by relatively basic VCS operations.
>>- None of the candies matter, as you only have 20 minutes (best case)
>>to show them the tool and set them on their way, and the candies require 
>> the
>>user to "get" version control in order to be appreciated.
>>
>> With the amount of time you have, you will be lucky to get 20% to
>> appreciate the fact they can restore any version they checked in in the
>> past. Showing them git because it can split a single change 

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Ohad Lutzky]

In the case that this is only a 20 minute lecture, I wholeheartedly agree. I
do think that git should be mentioned, in a one-liner, as "a more advanced
tool that also allows you to work offline".

So, while I agree that git is too complicated to learn in 20 minutes (takes
1-2 hours from my experience), it has a different upside when compared to
subversion: Administration is far easier. This is true for any DVCVS, and
stems from the fact that nobody needs write-access to anything but his own
files. Users will want to use whatever VCS is taught in order to
collaborate, and this requires some support work from the admins, which
should be taken into account. Either that or an alternative free,
easy-to-setup, fast and technion-accessible solution should be shown.

On Sun, Oct 18, 2009 at 8:37 AM, Shachar Shemesh wrote:

>  Ohad Lutzky wrote:
>
> Of course it would. But this one puts a lot of candy down that same path as
> well. These mines hurt, but are not fatal (again, from my experience, all
> mistakes can be recovered if detected within a reasonable time), and git's
> features make it, IMO, worth the trouble. For example, while many people
> find the staging area confusing (you have to "add" a file you've changed
> again in order to commit it, or just use commit -a to automatically add all
> changed files), it allows git to do awesome stuff like "git add -p"; this
> command goes over the differences from the previous version (like git diff),
> and asks you which hunks to stage. This means you can make a set of changes,
> realize it can be logically split into two, smaller sets of changes, and
> proceed to commit it as two sets of changes. Or, for a more common case, it
> allows you to stage only your actual fix to the commit without the various
> debugging statements you've added across your code in order to track down a
> bug, and do a quick "git reset --hard" afterwards.
>  There's a succinct list of reasons I like git here:
> http://whygitisbetterthanx.com/
>
>   I'm getting the sense that this conversation has gone off the main track
> a little. This is, I'll admit, also my fault. The question here is not
> "which VCS is better" (for which my answer, if you look at it, is
> "depends"), but "which VCS should we teach in the dev lecture of the W2L
> series".
>
> Here's the thing. When you first start to use a new system, what you see is
> mostly the mines. If this is the first system of its kind, you are likely to
> run into mines that are not really mines, but your misunderstanding of what
> the system is supposed to do, but still, the mines (real and conceptual) are
> mostly what you see. You do not, typically, see the candies, for the very
> simple reason that you do not understand the system well enough to
> appreciate or make use of them.
>
> As you use of the system matures, you learn to change your thinking to not
> regard some things as mines, and avoid the real ones. As that happens, the
> mines become less and less important, and the candies become more and more
> interesting. The main pre-requisite for that happening is that YOU HAVE NOT
> GIVEN UP ON THE TOOL!
>
> This thread started around a very specific question - should Haifux teach
> git, or some other version control system, as part of the development tools
> lecture. Any answer should take into account that amount of time given for
> this part of the lecture (between 10 and 20 minutes), and the amount of
> tutoring the students will have down the road (none unless they seek it).
> Under those conditions, in my opinion, git is the wrong tool because:
>
>- Anyone who has any experience with VCS will, likely, have used server
>based ones. Git, for them, contains all of the misconception mines that go
>with a distributed revision control
>- Git has some actual bone-fide mines, lain on the path traversed even
>by relatively basic VCS operations.
>- None of the candies matter, as you only have 20 minutes (best case)
>to show them the tool and set them on their way, and the candies require 
> the
>user to "get" version control in order to be appreciated.
>
> With the amount of time you have, you will be lucky to get 20% to
> appreciate the fact they can restore any version they checked in in the
> past. Showing them git because it can split a single change into multiple
> commits will fly so far over their heads, I'm afraid none of them will even
> run a single git command to even check out the water.
>
> Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>


-- 
Man is the only animal that laughs and weeps, for he is the only animal that
is struck with the difference between what things are and what they ought to
be.
- William Hazlitt

Ohad Lutzky
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Ohad Lutzky wrote:
Of course it would. But this one puts a lot of candy down that same 
path as well. These mines hurt, but are not fatal (again, from my 
experience, all mistakes can be recovered if detected within a 
reasonable time), and git's features make it, IMO, worth the trouble. 
For example, while many people find the staging area confusing (you 
have to "add" a file you've changed again in order to commit it, or 
just use commit -a to automatically add all changed files), it allows 
git to do awesome stuff like "git add -p"; this command goes over the 
differences from the previous version (like git diff), and asks you 
which hunks to stage. This means you can make a set of changes, 
realize it can be logically split into two, smaller sets of changes, 
and proceed to commit it as two sets of changes. Or, for a more common 
case, it allows you to stage only your actual fix to the commit 
without the various debugging statements you've added across your code 
in order to track down a bug, and do a quick "git reset --hard" 
afterwards.


There's a succinct list of reasons I like git 
here: http://whygitisbetterthanx.com/


I'm getting the sense that this conversation has gone off the main track 
a little. This is, I'll admit, also my fault. The question here is not 
"which VCS is better" (for which my answer, if you look at it, is 
"depends"), but "which VCS should we teach in the dev lecture of the W2L 
series".


Here's the thing. When you first start to use a new system, what you see 
is mostly the mines. If this is the first system of its kind, you are 
likely to run into mines that are not really mines, but your 
misunderstanding of what the system is supposed to do, but still, the 
mines (real and conceptual) are mostly what you see. You do not, 
typically, see the candies, for the very simple reason that you do not 
understand the system well enough to appreciate or make use of them.


As you use of the system matures, you learn to change your thinking to 
not regard some things as mines, and avoid the real ones. As that 
happens, the mines become less and less important, and the candies 
become more and more interesting. The main pre-requisite for that 
happening is that YOU HAVE NOT GIVEN UP ON THE TOOL!


This thread started around a very specific question - should Haifux 
teach git, or some other version control system, as part of the 
development tools lecture. Any answer should take into account that 
amount of time given for this part of the lecture (between 10 and 20 
minutes), and the amount of tutoring the students will have down the 
road (none unless they seek it). Under those conditions, in my opinion, 
git is the wrong tool because:


   * Anyone who has any experience with VCS will, likely, have used
 server based ones. Git, for them, contains all of the
 misconception mines that go with a distributed revision control
   * Git has some actual bone-fide mines, lain on the path traversed
 even by relatively basic VCS operations.
   * None of the candies matter, as you only have 20 minutes (best
 case) to show them the tool and set them on their way, and the
 candies require the user to "get" version control in order to be
 appreciated.

With the amount of time you have, you will be lucky to get 20% to 
appreciate the fact they can restore any version they checked in in the 
past. Showing them git because it can split a single change into 
multiple commits will fly so far over their heads, I'm afraid none of 
them will even run a single git command to even check out the water.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Ohad Lutzky]

Of course it would. But this one puts a lot of candy down that same path as
well. These mines hurt, but are not fatal (again, from my experience, all
mistakes can be recovered if detected within a reasonable time), and git's
features make it, IMO, worth the trouble. For example, while many people
find the staging area confusing (you have to "add" a file you've changed
again in order to commit it, or just use commit -a to automatically add all
changed files), it allows git to do awesome stuff like "git add -p"; this
command goes over the differences from the previous version (like git diff),
and asks you which hunks to stage. This means you can make a set of changes,
realize it can be logically split into two, smaller sets of changes, and
proceed to commit it as two sets of changes. Or, for a more common case, it
allows you to stage only your actual fix to the commit without the various
debugging statements you've added across your code in order to track down a
bug, and do a quick "git reset --hard" afterwards.
There's a succinct list of reasons I like git here:
http://whygitisbetterthanx.com/

On Sun, Oct 18, 2009 at 12:56 AM, Shachar Shemesh wrote:

>  Ohad Lutzky wrote:
>
> This is for their instructor to do, and for them to be taught about later
> on :) I'll only teach them how to check out older versions after I explain
> branches - that way they can be aware of the dangers of committing on
> non-branches.
>
> Wouldn't it be simpler to teach them a version control that does not put
> mines in your path?
>
> Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>


-- 
Man is the only animal that laughs and weeps, for he is the only animal that
is struck with the difference between what things are and what they ought to
be.
- William Hazlitt

Ohad Lutzky
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Ohad Lutzky wrote:
This is for their instructor to do, and for them to be taught about 
later on :)
I'll only teach them how to check out older versions after I explain 
branches - that way they can be aware of the dangers of committing on 
non-branches.
Wouldn't it be simpler to teach them a version control that does not put 
mines in your path?


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Ohad Lutzky]

This is for their instructor to do, and for them to be taught about later on
:)I'll only teach them how to check out older versions after I explain
branches - that way they can be aware of the dangers of committing on
non-branches.

On Sat, Oct 17, 2009 at 11:12 PM, Shachar Shemesh wrote:

>  Ohad Lutzky wrote:
>
> I specifically didn't teach them checkout, for this exact reason...
>
> To me, being able to check out an older version is the number 1 use of a
> version control system. I fail to see the use of the whole thing without it.
>
> Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>


-- 
Man is the only animal that laughs and weeps, for he is the only animal that
is struck with the difference between what things are and what they ought to
be.
- William Hazlitt

Ohad Lutzky
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Ohad Lutzky wrote:

I specifically didn't teach them checkout, for this exact reason...
To me, being able to check out an older version is the number 1 use of a 
version control system. I fail to see the use of the whole thing without it.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shlomi Fish]

On Friday 16 Oct 2009 09:17:57 Shachar Shemesh wrote:
> Tzafrir Cohen wrote:
> > I'm not sure I agree with you regarding version control systems.
> >
> > Specifically distributed version control systems make the common case of
> > a repository for the project simple. Unlike Subversion, you don't need
> > to set up a separate server.
> 
> You do not need to set up a separate server in subversion. "svnadmin
> create ~/svn ; svn co file:///home/sun/svn" is enough.
> 
> > And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
> > ex.c.orig and such.
> 
> Has anyone compared git's performance with file:// based svn? I'm not
> sure that claim holds.
> 

I once ran a large svn diff over a localhost http:// repository that I cloned 
from a remote opensvn.csie.org one (opensvn == very slow connectivity, based 
in Taiwan - but free for any legal use) using svnsync. It finished incredibly 
quickly - probably less than 3 seconds - maybe even less.

I didn't try it on a file:/// yet, but I tend to distrust file:/// Subversion 
URLs. Part of the problem with using Subversion over HTTP is that svn has so 
far stuck to a strict interpretation of the WebDAV/DeltaV standard:

http://blog.red-bean.com/sussman/?p=139

Reportedly (see above) this protocol implements ClearCase over HTTP, and has 
failed to gain acceptance, and is much more complex than needed. In svn-1.6 
they plan to use a less wasteful protocol, which will hopefully make things 
faster over sub-optimal connections such as WAN or Internet.

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
What does "Zionism" mean? - http://shlom.in/def-zionism

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

A note regarding your terminology:

On Sat, Oct 17, 2009 at 03:50:40AM +0200, Ohad Lutzky wrote:

> I still believe that with warning on those two issues, git is simple enough
> to use, and that the ability to work offline is well worth it.

"Work offline" is a problem only if the alternative is SVN or another
centralized system. If you just use files, you have no problems working
offline.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Ohad Lutzky]

I specifically didn't teach them checkout, for this exact reason... Yes,
warnings about these things are in order when you're using git.
(Specifically we have "always mind your current branch" and "rebasing is  a
destructive operation", but also "you can always fix these things if you
notice early enough", early enough being a rather loose from my experience).
On the specific matter of non-branch commits, git does some work to actively
warn you when you do so, but I think this could be improved.
I still believe that with warning on those two issues, git is simple enough
to use, and that the ability to work offline is well worth it.

On Fri, Oct 16, 2009 at 9:53 PM, Shachar Shemesh wrote:

>  Ohad Lutzky wrote:
>
>  As long as you're not doing rebases or working with multiple branches
> (which are much more complicated to do in SVN, and useless in the situation
> at any rate), the "data loss" problems mentioned above don't exist.
>
> Not true. The problem can happen if you just check out a commit which is
> not at the head of a branch (say, because you were doing regression
> testing), and then perform a commit. No branching required.
>
>  Git gives the added bonus of being able to work offline, which
> is indispensable for a student on a laptop.
>
> True, but it steps up the complexity considerably. Well, you step it up to
> begin with when you say that publishing your work requires two stages (three
> if you count the "add") - commit and then push. This means that for several
> people working on one repository, you would usually try to simplify things
> by telling them to git add + commit + push. Then, when you try take the
> laptop away, you find that you split an operation that used to be atomic,
> and the complexity comes back.
>
> True, working with a centralized repository means that this is downright
> impossible, but I still maintain that working offline is no novice task.
>
> Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>


-- 
Man is the only animal that laughs and weeps, for he is the only animal that
is struck with the difference between what things are and what they ought to
be.
- William Hazlitt

Ohad Lutzky
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Ohad Lutzky wrote:
 As long as you're not doing rebases or working with multiple branches 
(which are much more complicated to do in SVN, and useless in the 
situation at any rate), the "data loss" problems mentioned above don't 
exist.
Not true. The problem can happen if you just check out a commit which is 
not at the head of a branch (say, because you were doing regression 
testing), and then perform a commit. No branching required.
Git gives the added bonus of being able to work offline, which 
is indispensable for a student on a laptop.
True, but it steps up the complexity considerably. Well, you step it up 
to begin with when you say that publishing your work requires two stages 
(three if you count the "add") - commit and then push. This means that 
for several people working on one repository, you would usually try to 
simplify things by telling them to git add + commit + push. Then, when 
you try take the laptop away, you find that you split an operation that 
used to be atomic, and the complexity comes back.


True, working with a centralized repository means that this is downright 
impossible, but I still maintain that working offline is no novice task.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Doron Tal wrote:


Having said that, for the experienced git users, there is not reason 
to lose

their work, even in the case of some mistake.
For example, most problems can be recovered using:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes
I have to say I am even more worried than I was. It says there that any 
standard maintenance will destroy that data permanently. That is, 
actually, worse than I thought. To me, that is a "must never happen" 
situation.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Orna Agmon Ben-Yehuda]

How about a regular haifux slot, dedicated to source control applications wars?

On Fri, Oct 16, 2009 at 5:30 PM, Ohad Lutzky  wrote:
> I tend to disagree about git being too complex. I currently have three
> students (in a military setting), which have never used any form of version
> control before, and have been taught basic usage of git - init, add, commit,
> log, diff, remote, and pull. I've received no complaints as of yet. As long
> as you're not doing rebases or working with multiple branches (which are
> much more complicated to do in SVN, and useless in the situation at any
> rate), the "data loss" problems mentioned above don't exist. Git gives the
> added bonus of being able to work offline, which is indispensable for a
> student on a laptop.
> --
> Man is the only animal that laughs and weeps, for he is the only animal that
> is struck with the difference between what things are and what they ought to
> be.
> - William Hazlitt
>
> Ohad Lutzky
>
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
>
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

On Fri, Oct 16, 2009 at 01:35:09PM +0200, boazg wrote:
> it seems that on t2 (now called stud) you can use not only file:/// but also
> svn+ssh://, with only a student account. in that case i agree that
> subversion is much better than git for this purpose.

git works just as well with git-over-ssh repositories. Alternatively you
can also use the http method to provide a public repository off t2 from
your homepage :-)

(Just make sure to 'chown +x .git/hooks/post-update' At least here -
Debian Lenny - this makes a repository run the required
git-update-server-info)

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

On Fri, Oct 16, 2009 at 10:05:14AM +0200, Vadim Eisenberg wrote:
> guy keren wrote:
> > you can mention memory leaks if you want - but students don't care about 
> > them so much, because it doesn't break their programs.
> 
> Starting from the Winter 2008-2009 semester, the memory leaks are 
> checked in Matam (Introduction to Systems Programming) course and 1 
> point is reduced for each leak. The check is done automatically, 
> using, guess what, valgrind. So the students in Matam actually care
> very much about the memory leaks.

... which are detectable by valgrind :-)

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Ohad Lutzky]

I tend to disagree about git being too complex. I currently have three
students (in a military setting), which have never used any form of version
control before, and have been taught basic usage of git - init, add, commit,
log, diff, remote, and pull. I've received no complaints as of yet. As long
as you're not doing rebases or working with multiple branches (which are
much more complicated to do in SVN, and useless in the situation at any
rate), the "data loss" problems mentioned above don't exist. Git gives the
added bonus of being able to work offline, which is indispensable for a
student on a laptop.
-- 
Man is the only animal that laughs and weeps, for he is the only animal that
is struck with the difference between what things are and what they ought to
be.
- William Hazlitt

Ohad Lutzky
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Doron Tal]

I tend to agree that git is somewhat complex for the novice. It takes awhile
before one feels comfortable working with git. SCMs in general, are not
considered
"core" learning material, so most student will prefer to avoid "wasting"
their
time to earn the required expertise.

Having said that, for the experienced git users, there is not reason to lose
their work, even in the case of some mistake.
For example, most problems can be recovered using:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes

Another, less powerful tool, but good enough for immediate disaster recovery
is the ORIG_HEAD reference.

--doron

On Thu, Oct 15, 2009 at 11:38 PM, guy keren  wrote:

>
> the problem with git, is that it's very easy to shoot yourself in the
> foot. giving it to students, who might accidentally reset their
> repository into losing their code, is not a very good idea, if you don't
> have time to give a proper explanation plus warnings.
>
> --guy
>
> Tzafrir Cohen wrote:
> > On Thu, Oct 15, 2009 at 09:13:58PM +0200, Eli Billauer wrote:
> >> OK, I think this is a good time to express my view regarding the
> >> "Development tools" lecture. It's purpose, as I see it, is to give the
> >> students a nice start with the "right" tools for developing code, as
> >> needed for their exercises. If their experience is good, they'll stay.
> >> If not, they'll soon use the alternatives.
> >>
> >>
> >> If you want to give a lecture about any other subject, as a
> >> Stay-in-Linux or mainstream lecture, by all means come forward. But
> >> let's try to get some focus on the initial lecture.
> >>
> >>
> >> Correct me if I'm wrong, but a student is not likely to go beyond a
> >> project which runs on a single platform, having a few source files, and
> >> with no more than two or three persons involved. Hence autotools are
> >> irrelevant, and so are version control systems. Tarballing all sources,
> >> and sending to your partner with comments, is as much version control as
> >> you need in these situations.
> >
> > I'm not sure I agree with you regarding version control systems.
> >
> > Specifically distributed version control systems make the common case of
> > a repository for the project simple. Unlike Subversion, you don't need
> > to set up a separate server.
> >
> > And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
> > ex.c.orig and such. I think that demonstarting simple linear workflow
> > (no branches, no remote repositories) with git, bzr or hg could be handy.
> >
>
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[boazg]

it seems that on t2 (now called stud) you can use not only file:/// but also
svn+ssh://, with only a student account. in that case i agree that
subversion is much better than git for this purpose.

as for the question of why do you need version control for something as
simple as MATAM, it really makes a huge difference from my experience. it
saves alot of the "ok i did this now you do this" and the "crap we messed up
let's hope there's a backup of this in my inbox" and lets you focus on the
work. while some students may be skeptical, this IMHO will become a killer
app and a must for many students and may give us an upper hand.

On Fri, Oct 16, 2009 at 10:05, Vadim Eisenberg wrote:

> guy keren wrote:
> > you can mention memory leaks if you want - but students don't care about
> them so much, because it doesn't break their programs.
>
> Starting from the Winter 2008-2009 semester, the memory leaks are checked
> in Matam (Introduction to Systems Programming) course and 1 point is reduced
> for each leak. The check is done automatically, using, guess what, valgrind.
> So the students in Matam actually care very much about the memory leaks.
>
> Vadim
>
> -Original Message-
> From: haifux-boun...@haifux.org [mailto:haifux-boun...@haifux.org] On
> Behalf Of guy keren
> Sent: Friday, October 16, 2009 9:47 AM
> To: Eli Billauer
> Cc: Haifa Linux Club
> Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"
>
> Eli Billauer wrote:
> > guy keren wrote:
> >
> >>
> >> what - no valgrind?
> >>
> > I stand corrected. A quick demonstration of valgrind (show how it
> > detects memory leaks and access to unallocated/uninitialized memory)
> > is in place. It's definitely something handy for a student, and it's
> > so simple to use.
> >
> >   Eli
> >
>
> i think the best demo for valgrind would be:
>
> 1. this step should be done at home: write a program that has a non-obvious
> problem with corrupting its memory (make sure that when you run it, it
> actually crashes)
>
> 2. the next steps will be done during the demonstration: show it to the
> people (the source, how the program crashes, and how you fail to find the
> problem even when the crash is done inside gdb)
>
> 3. show them how you find the bug within seconds using valgrind.
>
> you can mention memory leaks if you want - but students don't care about
> them so much, because it doesn't break their programs. they do care about
> memory corruption if it indeed causes their program to crash.
>
> --guy
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>



-- 

Mike Ditka <http://www.brainyquote.com/quotes/authors/m/mike_ditka.html>  -
"If God had wanted man to play soccer, he wouldn't have given us arms."
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Vadim Eisenberg]

guy keren wrote:
> you can mention memory leaks if you want - but students don't care about them 
> so much, because it doesn't break their programs.

Starting from the Winter 2008-2009 semester, the memory leaks are checked in 
Matam (Introduction to Systems Programming) course and 1 point is reduced for 
each leak. The check is done automatically, using, guess what, valgrind. So the 
students in Matam actually care very much about the memory leaks.

Vadim

-Original Message-
From: haifux-boun...@haifux.org [mailto:haifux-boun...@haifux.org] On Behalf Of 
guy keren
Sent: Friday, October 16, 2009 9:47 AM
To: Eli Billauer
Cc: Haifa Linux Club
Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

Eli Billauer wrote:
> guy keren wrote:
> 
>>
>> what - no valgrind?
>>
> I stand corrected. A quick demonstration of valgrind (show how it 
> detects memory leaks and access to unallocated/uninitialized memory) 
> is in place. It's definitely something handy for a student, and it's 
> so simple to use.
> 
>   Eli
> 

i think the best demo for valgrind would be:

1. this step should be done at home: write a program that has a non-obvious 
problem with corrupting its memory (make sure that when you run it, it actually 
crashes)

2. the next steps will be done during the demonstration: show it to the people 
(the source, how the program crashes, and how you fail to find the problem even 
when the crash is done inside gdb)

3. show them how you find the bug within seconds using valgrind.

you can mention memory leaks if you want - but students don't care about them 
so much, because it doesn't break their programs. they do care about memory 
corruption if it indeed causes their program to crash.

--guy
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[guy keren]

Eli Billauer wrote:
> guy keren wrote:
> 
>>
>> what - no valgrind?
>>
> I stand corrected. A quick demonstration of valgrind (show how it 
> detects memory leaks and access to unallocated/uninitialized memory) is 
> in place. It's definitely something handy for a student, and it's so 
> simple to use.
> 
>   Eli
> 

i think the best demo for valgrind would be:

1. this step should be done at home: write a program that has a 
non-obvious problem with corrupting its memory (make sure that when you 
run it, it actually crashes)

2. the next steps will be done during the demonstration: show it to the 
people (the source, how the program crashes, and how you fail to find 
the problem even when the crash is done inside gdb)

3. show them how you find the bug within seconds using valgrind.

you can mention memory leaks if you want - but students don't care about 
them so much, because it doesn't break their programs. they do care 
about memory corruption if it indeed causes their program to crash.

--guy
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Vadim Eisenberg wrote:


> Eclipse doesn't belong to the "right" tools, in my opinion.

 

Why Eclipse doesn't belong to the "right" tools ? My naïve 
understanding is that Eclipse is Emacs of the 21-st century – it is 
open source, customizable etc., similar to Emacs; in addition to being 
graphical.


Thank you! I was wondering why I hated Eclipse so much, and you have put 
your finger on it. It's exactly like a 21-st century Emacs.


Shachar

p.s.
I'm not so sure it is a bad idea to teach Eclipse. I think it's worth 
mentioning that eclipse exists, but to just point them in the right 
direction, and then teach the basics.


--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

Tzafrir Cohen wrote:


I'm not sure I agree with you regarding version control systems.

Specifically distributed version control systems make the common case of
a repository for the project simple. Unlike Subversion, you don't need
to set up a separate server.

  
You do not need to set up a separate server in subversion. "svnadmin 
create ~/svn ; svn co file:///home/sun/svn" is enough.

And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
ex.c.orig and such.
Has anyone compared git's performance with file:// based svn? I'm not 
sure that claim holds.

 I think that demonstarting simple linear workflow
(no branches, no remote repositories) with git, bzr or hg could be handy.

  
Guy has already responded with some "shooting yourself in the foot", but 
I'll elaborate. Git makes it exceedingly easy to reach situations in 
which information is either actually lost, or is not technically lost, 
but is unreachable without searching in internal log files. The most 
problematic one to chance upon by accident is off branch commits (where 
you revert to an old version, make changes and commit them by mistake). 
I read somewhere an explanation of how to recover from this situation. 
It started by explaining how lucky he was to have spotted that that was 
what he did before he checked out another branch (if you do, the only 
way to find your commits is the afore mentioned internal log files). He 
then goes on to list the steps required to recover the file, and ends 
with "viola! it's like magic", with a footnote stating that "like magic" 
means it is a list of arbitrary and hard to remember incantations in 
which getting the slightest thing wrong means a catastrophe.


At least the other case, where data is actually lost, is unlikely to get 
at if you only work with one repository[1].


In short, I'm with Guy on this one. Git is an extremely powerful tool, 
but it is only useful once you master the right way to tread and where. 
In other words - not a good choice for a novice[2].


Shachar

1
The rebase operation actually changes the history. After a branch 
rebase, the tree is reworked to look as if the branch has always 
branched off the new rebase point. This means that the precise tree 
layout before the rebase operation is no longer reachable. It is no 
longer possible to check out the version that compiled fine before the 
rebase.


I don't remember the precise details at the moment to say whether every 
rebase is like that, or whether it's only sometimes. I will say that, in 
my book, a version control that allows an operation that is not undoable 
is not a version control.


As I write this, it occures to me that this may actually be the precise 
same problem as the one I pointed above, and the previous end point for 
the branch is still in the repository, it just doesn't have a name, and 
if you know the commit's name, you can still check it out. That does not 
change my above statement - it is a no-no for a version control system.


2
In my opinion, also not a good choice for anyone who relies on 
centralized backups (like a commercial company), not a good choice for 
anyone who does not perform multi-commiters multi-versions development. 
In other words, there are very few cases, aside from the Linux kernel 
itself, where it IS a good choice. Also, I often find where even where 
it is a good choice (such as Wine, where an off trunk personal 
development branch might be long and convulted), it is not used properly 
(the development model does not support a "git pull" and multi commiters 
- only patch sending).


In the android case, it is the best choice available (multiple 
repositories, independently developed in parallel, with partial code 
sharing between them), but has significant drawbacks (no support for 
multiple repository checkouts, no support for partial tree checkouts) 
which are worked around with a wrapper tool.


--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Vadim Eisenberg]

> Eclipse doesn't belong to the "right" tools, in my opinion.

 

Why Eclipse doesn't belong to the "right" tools ? My naïve understanding is 
that Eclipse is Emacs of the 21-st century – it is open source, customizable 
etc., similar to Emacs; in addition to being graphical. Maybe I miss something 
- what are the advantages of Emacs over Eclipse ?

 

Vadim

 

From: haifux-boun...@haifux.org [mailto:haifux-boun...@haifux.org] On Behalf Of 
Eli Billauer
Sent: Thursday, October 15, 2009 9:14 PM
To: Tzafrir Cohen
Cc: Haifa Linux Club
Subject: Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

 

OK, I think this is a good time to express my view regarding the "Development 
tools" lecture. It's purpose, as I see it, is to give the students a nice start 
with the "right" tools for developing code, as needed for their exercises. If 
their experience is good, they'll stay. If not, they'll soon use the 
alternatives.

 

If you want to give a lecture about any other subject, as a Stay-in-Linux or 
mainstream lecture, by all means come forward. But let's try to get some focus 
on the initial lecture.

 

Correct me if I'm wrong, but a student is not likely to go beyond a project 
which runs on a single platform, having a few source files, and with no more 
than two or three persons involved. Hence autotools are irrelevant, and so are 
version control systems. Tarballing all sources, and sending to your partner 
with comments, is as much version control as you need in these situations.

 

Eclipse doesn't belong to the "right" tools, in my opinion.

 

I would therefore set the following goals to a CS development tools intro 
lecture:

 

1. Being able to compile the sources (objects and executable), including math 
libraries and such, with reasonable flags (optimization, debug info, -Wall etc) 
with gcc.

2. Using make properly. No crazy tricks, just getting the actions and 
dependencies right.

3. Using vi/vim/emacs (show both, explain why both are good). I wouldn't bother 
showing many keystrokes, just demonstrating and pointing at where you can get a 
good reference for them.

4. Use ddd for debugging. It's worth mentioning that it's based upon gdb, and 
that gdb commands can be given directly (demonstrate?) but using gdb to start 
with is not convincing at all.

 

More is less. My $.02.

 

   Eli

 

Tzafrir Cohen wrote:

On Thu, Oct 15, 2009 at 05:14:50PM +0200, boazg wrote:
  

as a side note, a seperate lecture on git for CS students, and how to use it
with t2 would be a good idea.


 
Why git?
 
While I think git is a handy tool, did you have in mind "developement
tools"?
 
Other tools that come in mind:
 
gcc
make
vi / vim
gdb
autotools
emacs
kdevelop
eclipse
 
(Just a list of tools from the top of my head, I don't intend to start a
flame war on the exact content of a non-existing lecture)
 
  






-- 
Web: http://www.billauer.co.il
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Eli Billauer]

guy keren wrote:

>
> what - no valgrind?
>
I stand corrected. A quick demonstration of valgrind (show how it 
detects memory leaks and access to unallocated/uninitialized memory) is 
in place. It's definitely something handy for a student, and it's so 
simple to use.

   Eli

-- 
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[guy keren]

the problem with git, is that it's very easy to shoot yourself in the 
foot. giving it to students, who might accidentally reset their 
repository into losing their code, is not a very good idea, if you don't 
have time to give a proper explanation plus warnings.

--guy

Tzafrir Cohen wrote:
> On Thu, Oct 15, 2009 at 09:13:58PM +0200, Eli Billauer wrote:
>> OK, I think this is a good time to express my view regarding the  
>> "Development tools" lecture. It's purpose, as I see it, is to give the  
>> students a nice start with the "right" tools for developing code, as  
>> needed for their exercises. If their experience is good, they'll stay.  
>> If not, they'll soon use the alternatives.
>>
>>
>> If you want to give a lecture about any other subject, as a  
>> Stay-in-Linux or mainstream lecture, by all means come forward. But  
>> let's try to get some focus on the initial lecture.
>>
>>
>> Correct me if I'm wrong, but a student is not likely to go beyond a  
>> project which runs on a single platform, having a few source files, and  
>> with no more than two or three persons involved. Hence autotools are  
>> irrelevant, and so are version control systems. Tarballing all sources,  
>> and sending to your partner with comments, is as much version control as  
>> you need in these situations.
> 
> I'm not sure I agree with you regarding version control systems.
> 
> Specifically distributed version control systems make the common case of
> a repository for the project simple. Unlike Subversion, you don't need
> to set up a separate server.
> 
> And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
> ex.c.orig and such. I think that demonstarting simple linear workflow
> (no branches, no remote repositories) with git, bzr or hg could be handy.
> 

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[guy keren]

what - no valgrind?

it's the one killer application that might save students many nights of 
pulling out their hair.

of-course, we can go the asimov way ("profession day") and claim they 
need to go through some such nights before they are introduced to the 
blessing of valgrind...

--guy

Eli Billauer wrote:
> OK, I think this is a good time to express my view regarding the 
> "Development tools" lecture. It's purpose, as I see it, is to give the 
> students a nice start with the "right" tools for developing code, as 
> needed for their exercises. If their experience is good, they'll stay. 
> If not, they'll soon use the alternatives.
> 
> 
> If you want to give a lecture about any other subject, as a 
> Stay-in-Linux or mainstream lecture, by all means come forward. But 
> let's try to get some focus on the initial lecture.
> 
> 
> Correct me if I'm wrong, but a student is not likely to go beyond a 
> project which runs on a single platform, having a few source files, and 
> with no more than two or three persons involved. Hence autotools are 
> irrelevant, and so are version control systems. Tarballing all sources, 
> and sending to your partner with comments, is as much version control as 
> you need in these situations.
> 
> 
> Eclipse doesn't belong to the "right" tools, in my opinion.
> 
> 
> I would therefore set the following goals to a CS development tools 
> intro lecture:
> 
> 
> 1. Being able to compile the sources (objects and executable), including 
> math libraries and such, with reasonable flags (optimization, debug 
> info, -Wall etc) with gcc.
> 
> 2. Using make properly. No crazy tricks, just getting the actions and 
> dependencies right.
> 
> 3. Using vi/vim/emacs (show both, explain why both are good). I wouldn't 
> bother showing many keystrokes, just demonstrating and pointing at where 
> you can get a good reference for them.
> 
> 4. Use ddd for debugging. It's worth mentioning that it's based upon 
> gdb, and that gdb commands can be given directly (demonstrate?) but 
> using gdb to start with is not convincing at all.
> 
> 
> More is less. My $.02.
> 
> 
>Eli
> 
> 
> Tzafrir Cohen wrote:
> 
>> On Thu, Oct 15, 2009 at 05:14:50PM +0200, boazg wrote:
>>   
>>> as a side note, a seperate lecture on git for CS students, and how to use it
>>> with t2 would be a good idea.
>>> 
>>
>> Why git?
>>
>> While I think git is a handy tool, did you have in mind "developement
>> tools"?
>>
>> Other tools that come in mind:
>>
>> gcc
>> make
>> vi / vim
>> gdb
>> autotools
>> emacs
>> kdevelop
>> eclipse
>>
>> (Just a list of tools from the top of my head, I don't intend to start a
>> flame war on the exact content of a non-existing lecture)
>>
>>   
> 
> 
> -- 
> Web: http://www.billauer.co.il
> 
> 
> 
> 
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

On Thu, Oct 15, 2009 at 09:13:58PM +0200, Eli Billauer wrote:
> OK, I think this is a good time to express my view regarding the  
> "Development tools" lecture. It's purpose, as I see it, is to give the  
> students a nice start with the "right" tools for developing code, as  
> needed for their exercises. If their experience is good, they'll stay.  
> If not, they'll soon use the alternatives.
>
>
> If you want to give a lecture about any other subject, as a  
> Stay-in-Linux or mainstream lecture, by all means come forward. But  
> let's try to get some focus on the initial lecture.
>
>
> Correct me if I'm wrong, but a student is not likely to go beyond a  
> project which runs on a single platform, having a few source files, and  
> with no more than two or three persons involved. Hence autotools are  
> irrelevant, and so are version control systems. Tarballing all sources,  
> and sending to your partner with comments, is as much version control as  
> you need in these situations.

I'm not sure I agree with you regarding version control systems.

Specifically distributed version control systems make the common case of
a repository for the project simple. Unlike Subversion, you don't need
to set up a separate server.

And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
ex.c.orig and such. I think that demonstarting simple linear workflow
(no branches, no remote repositories) with git, bzr or hg could be handy.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

On Thu, Oct 15, 2009 at 08:17:22PM +0200, Orna Agmon Ben-Yehuda wrote:
> Great idea. Can you do this? We have not had anything on source
> control since Tzahi Fadida's CVS.

You're right. We had a lecture about Git, but it's not a Version Control
System :-)

http://www.haifux.org/lectures/182/

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Eli Billauer]

OK, I think this is a good time to express my view regarding the 
"Development tools" lecture. It's purpose, as I see it, is to give the 
students a nice start with the "right" tools for developing code, as 
needed for their exercises. If their experience is good, they'll stay. 
If not, they'll soon use the alternatives.



If you want to give a lecture about any other subject, as a 
Stay-in-Linux or mainstream lecture, by all means come forward. But 
let's try to get some focus on the initial lecture.



Correct me if I'm wrong, but a student is not likely to go beyond a 
project which runs on a single platform, having a few source files, and 
with no more than two or three persons involved. Hence autotools are 
irrelevant, and so are version control systems. Tarballing all sources, 
and sending to your partner with comments, is as much version control as 
you need in these situations.



Eclipse doesn't belong to the "right" tools, in my opinion.


I would therefore set the following goals to a CS development tools 
intro lecture:



1. Being able to compile the sources (objects and executable), including 
math libraries and such, with reasonable flags (optimization, debug 
info, -Wall etc) with gcc.


2. Using make properly. No crazy tricks, just getting the actions and 
dependencies right.


3. Using vi/vim/emacs (show both, explain why both are good). I wouldn't 
bother showing many keystrokes, just demonstrating and pointing at where 
you can get a good reference for them.


4. Use ddd for debugging. It's worth mentioning that it's based upon 
gdb, and that gdb commands can be given directly (demonstrate?) but 
using gdb to start with is not convincing at all.



More is less. My $.02.


  Eli


Tzafrir Cohen wrote:


On Thu, Oct 15, 2009 at 05:14:50PM +0200, boazg wrote:
  

as a side note, a seperate lecture on git for CS students, and how to use it
with t2 would be a good idea.



Why git?

While I think git is a handy tool, did you have in mind "developement
tools"?

Other tools that come in mind:

gcc
make
vi / vim
gdb
autotools
emacs
kdevelop
eclipse

(Just a list of tools from the top of my head, I don't intend to start a
flame war on the exact content of a non-existing lecture)

  



--
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Dotan Cohen]

2009/10/15 boazg <>:
> as a side note, a seperate lecture on git for CS students, and how to use it
> with t2 would be a good idea.

As a subside note, a separate lecture on getting the
video.technion.ac.il site videos working in Linux would be great. VLC
plays them, but not at 150% speed or other effects. This is rather
important for video lectures.

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Orna Agmon Ben-Yehuda]

Great idea. Can you do this? We have not had anything on source
control since Tzahi Fadida's CVS.

Tzafrir - Development tools will be given, covering such topics.

On Thu, Oct 15, 2009 at 5:14 PM, boazg  wrote:
> as a side note, a seperate lecture on git for CS students, and how to use it
> with t2 would be a good idea.
>
> On Thu, Oct 15, 2009 at 16:44, Eli Billauer  wrote:
>>
>> Hello again.
>>
>> The FOSS lecture will be held by Orr (I have to admit I wasn't aware
>> that he's a candidate). There were several other eligible lecturers who
>> came forward, but being the club's founder, Orr has a somewhat natural
>> advantage (on top of his well-known preaching skills). ;)
>>
>> Shahar Dag (the SSDL lab's engineer and a Haifux member) will take the
>> Configuration party from here. Please coordinate your activities with
>> him. Those of you who have already volunteered for this, will be
>> contacted by Shahar soon. Since there's much logistics in an event like
>> this, I believe it's best headed by the one who runs the location.
>>
>> Thank you all for the good spirit. Let's keep it up this way!
>>
>>   Eli
>>
>>
>>
>>
>> --
>> Web: http://www.billauer.co.il
>>
>> ___
>> Haifux mailing list
>> Haifux@haifux.org
>> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
>
>
> --
>
> Stephen Leacock  - "I detest life-insurance agents: they always argue that I
> shall some day die, which is not so."
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
>
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Tzafrir Cohen]

On Thu, Oct 15, 2009 at 05:14:50PM +0200, boazg wrote:
> as a side note, a seperate lecture on git for CS students, and how to use it
> with t2 would be a good idea.

Why git?

While I think git is a handy tool, did you have in mind "developement
tools"?

Other tools that come in mind:

gcc
make
vi / vim
gdb
autotools
emacs
kdevelop
eclipse

(Just a list of tools from the top of my head, I don't intend to start a
flame war on the exact content of a non-existing lecture)

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[boazg]

as a side note, a seperate lecture on git for CS students, and how to use it
with t2 would be a good idea.

On Thu, Oct 15, 2009 at 16:44, Eli Billauer  wrote:

> Hello again.
>
> The FOSS lecture will be held by Orr (I have to admit I wasn't aware
> that he's a candidate). There were several other eligible lecturers who
> came forward, but being the club's founder, Orr has a somewhat natural
> advantage (on top of his well-known preaching skills). ;)
>
> Shahar Dag (the SSDL lab's engineer and a Haifux member) will take the
> Configuration party from here. Please coordinate your activities with
> him. Those of you who have already volunteered for this, will be
> contacted by Shahar soon. Since there's much logistics in an event like
> this, I believe it's best headed by the one who runs the location.
>
> Thank you all for the good spirit. Let's keep it up this way!
>
>   Eli
>
>
>
>
> --
> Web: http://www.billauer.co.il
>
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>



-- 

Stephen 
Leacock
- "I detest life-insurance agents: they always argue that I shall some
day
die, which is not so."
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Eli Billauer]

Hello again.

The FOSS lecture will be held by Orr (I have to admit I wasn't aware 
that he's a candidate). There were several other eligible lecturers who 
came forward, but being the club's founder, Orr has a somewhat natural 
advantage (on top of his well-known preaching skills). ;)

Shahar Dag (the SSDL lab's engineer and a Haifux member) will take the 
Configuration party from here. Please coordinate your activities with 
him. Those of you who have already volunteered for this, will be 
contacted by Shahar soon. Since there's much logistics in an event like 
this, I believe it's best headed by the one who runs the location.

Thank you all for the good spirit. Let's keep it up this way!

   Eli




-- 
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Shlomi Fish]

ׁHi Eli!

Sending only to the Haifux mailing list. Maybe I'll forward it to 
w...@projects.hamakor.org.il later on.

On Wednesday 14 Oct 2009 15:00:55 Eli Billauer wrote:
> Hello,
> 
> 
> We are in the midst of the preparations for the next W2L. As it turns
> out, there's a need for a few of you to occupy the following functions.
> If you feel like doing any (or both), please email me *privately* (I see
> no point in making a thread of this).
> 
> 
> 1. The "FOSS Philosophy" lecture on 2/11/2009 (both the lecture's name
> and date are negotiable). Orna will not be able to deliver it, and we
> would like to have one fairly down-to-earth talk about the ideology and
> methodology behind FOSS. In case I didn't make this clear: This is a
> once-in-life opportunity to preach before a herd of misguided souls...
> 
> 
> 2. We need "Linux gurus": People to offer help and advice during the
> "Configuration Party" on 3/11/2009. We expect people with partially
> installed machines to show up asking to get their computers fully
> configured. I wouldn't rule out from-scratch installations as well. The
> location is the SSDL lab with spare hardware handy (monitors, mice,
> keyboards etc), so the conditions are ideal.
> 

Sounds good. Thanks for the initiative!

Would you like to cooperate with Telux/TelFOSS on the Welcome-to-FOSS 
initiative? http://welcome.foss.org.il/2009/ . I've already updated the front 
page and plan to revamp more soon. I should note that I have no problem with 
Haifux focusing on "Welcome-to-Linux" instead of the more general "Welcome-to-
FOSS", but all the participating Israeli clubs should probably have a unified 
site there.

If you feel like discussing the series in its global aspect, please subscribe 
to http://hamakor.org.il/cgi-bin/mailman/listinfo/w2l .

I may attend the configuration party and stuff, given that someone can give me 
a ride from Tel Aviv, and that I will feel calm enough at that day. 

Regards,

Shlomi Fish

> 
> Please contact me directly if you're ready to participate.
> 
> 
> Thanks in advance.
> 
> Eli
> 

-- 
-
Shlomi Fish   http://www.shlomifish.org/
What Makes Software Apps High Quality -  http://shlom.in/sw-quality

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Re: [Haifux] [W2L] Call for lecturer + "Linux guru"

[Dotan Cohen]

> 1. The "FOSS Philosophy" lecture on 2/11/2009 (both the lecture's name
> and date are negotiable). Orna will not be able to deliver it, and we
> would like to have one fairly down-to-earth talk about the ideology and
> methodology behind FOSS. In case I didn't make this clear: This is a
> once-in-life opportunity to preach before a herd of misguided souls...
>

At what hour? I finish studing that day at 17:30


> 2. We need "Linux gurus": People to offer help and advice during the
> "Configuration Party" on 3/11/2009. We expect people with partially
> installed machines to show up asking to get their computers fully
> configured. I wouldn't rule out from-scratch installations as well. The
> location is the SSDL lab with spare hardware handy (monitors, mice,
> keyboards etc), so the conditions are ideal.
>

I can help with new installations, but probably won't be much use for
fixing botched installs. Though to be honest, _anybody_ can handle a
new install these days. I have an official Kubuntu 9.04 disc, and
Kubuntu 9.10 should be out by then and I can bring a few copies.


> Please contact me directly if you're ready to participate.
>

I haven't decided yet, therefore I post on list as others may have the
same question.

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux