I've started another thread asking about Vmware. Is anyone here using Vmware?
I was for a few years, but am now using qemu.
It's better for me, but that may be because I use FreeBSD and VMware ports for FreeBSD aren't as up-to-date as VMware.
It's also cheaper.
On Thu, Sep 07, 2006 at 01:06:08PM +0000, Christopher Dawkins wrote:
I've started another thread asking about Vmware. Is anyone here using Vmware?
I was for a few years, but am now using qemu.
It's better for me, but that may be because I use FreeBSD and VMware ports for FreeBSD aren't as up-to-date as VMware.
It's also cheaper.
Cheaper than free? Both Vmware server and Vmware player are now available for nothing.
cl@isbd.net wrote:
Cheaper than free? Both Vmware server and Vmware player are now available for nothing.
However, 14 other VMware products are not, AFAICT. Also, one may study qemu and adapt it to your needs (such as FreeBSD support), or have it adapted, in a free market way, and its licensing does not limit your server memory size, or impose other bizarre arbitrary restrictions.
Hope that helps,
MJ Ray wrote:
However, 14 other VMware products are not, AFAICT. Also, one may study qemu and adapt it to your needs (such as FreeBSD support), or have it adapted, in a free market way, and its licensing does not limit your server memory size, or impose other bizarre arbitrary restrictions.
I recently decided to do precisely this (not with Qemu, but with a GPL licenced home accounts package), and I quickly realised just how much stuff I don't know (and need to know) just to get started.
In this case the package is cross-platform and uses wxWidgets, but the instructions I had to get set up were Windows based (using the free-as-in-beer MS Visual C++ Express as the compiler), and I decided to follow that route (for a whole range of reasons which aren't relevant here). The problems I had getting started were probably fairly generic, though.
I realised that whilst I've occasionally used CVS in the past I didn't really know what I was doing with SVN, so that was hurdle number one. Installing all the relevant libraries and getting all of those to compile was a major hurdle (and I'd like to think it was because of the platform I was on but I don't really think that's true). Getting the actual application to compile when I got that far was easy, but then (it surprised me to realise) I didn't know how to generate diffs (again the platform didn't help, but I wouldn't actually have been any more able under Linux). And I'm fairly technically literate, have been coding in various languages since I was about 11 (ZX81 basic!!), and I really should know better.
So the point I'm getting at is that the barrier to entry to FOSS development seems very high and I couldn't find any simple getting started guides (maybe I didn't look far enough). SVN is one of those packages which is really well documented, but I didn't need that - I just wanted to get the latest code onto my PC, know how to get updates, and how to submit patches. wxWidgets is similarly well documented but I simply couldn't compile it, and to be honest probably shouldn't have needed to: binary library files would have been enough for what I wanted to do.
There are so many applications out there which probably just need one or two line fixes here and there to improve them, but whilst the code change might take a few minutes (in my case that is how long it took to fix the bug that I was hunting for) it took about a fortnight of playing around to get to a position where I could start. (And doesn't C++ take a long time to compile!) // Not sure if this is just a rant, or whether I'm asking for help somewhere. If there is a good "getting started in FOSS development" book I'd like to know about it. Something with a bright yellow colour aimed at "Dummies" might be useful! But these days teaching kids to use computers in school means teaching them to use office (and usually Office[tm]) applications, not teaching them how to program. FOSS is missing a trick if the barrier to entry can't be lowered so that the ideal of fixing those bugs that annoy you then submitting them back to the community can actually be achieved by a moderately competent person in the real world.
On Fri, Sep 08, 2006 at 09:01:59AM +0100, Mark Rogers wrote:
So the point I'm getting at is that the barrier to entry to FOSS development seems very high and I couldn't find any simple getting started guides (maybe I didn't look far enough). SVN is one of those packages which is really well documented, but I didn't need that - I just wanted to get the latest code onto my PC, know how to get updates, and how to submit patches. wxWidgets is similarly well documented but I simply couldn't compile it, and to be honest probably shouldn't have needed to: binary library files would have been enough for what I wanted to do.
I think one of the things that can be difficult is the major difference in "shape/philosophy" between development in a Unix(ish) environment and a Windows(ish) one.
I come from many years of Unix development (I started writing C on Unix sometime in the 1980s) and have done virtually no coding on MS/Windows machines.
I find it very difficult indeed to do anything useful programming wise on Windows, when Linux came along and allowed me into a familiar environment on a cheap PC that I could have at home it was wonderful!
In general I don't find too much difficulty in building things on my Slackware system though, inevitably, there are "dependency nightmares" sometimes.
There are so many applications out there which probably just need one or two line fixes here and there to improve them, but whilst the code change might take a few minutes (in my case that is how long it took to fix the bug that I was hunting for) it took about a fortnight of playing around to get to a position where I could start. (And doesn't C++ take a long time to compile!)
In some ways I think a bit of a significant learning curve may not be a bad idea. There needs to be some sort of level of competance before someone starts submitting code changes. I'm desperately trying not to sound elitist here! :-) I suppose it's akin to the problem of protecting Wikis from antisocial/incompetant people.
cl@isbd.net wrote:
I think one of the things that can be difficult is the major difference in "shape/philosophy" between development in a Unix(ish) environment and a Windows(ish) one.
Yes, this is true, but not so much with a cross-platform OSS development where the philosophies have more in common.
As I mentioned I did have the option of compiling under Linux; but when I looked at it I had exactly the same questions as under Windows (I still didn't know my way around SVN, wxWidgets, etc). I stuck with Windows mainly because I needed to test the final application under Windows, for other less enlightened folk in the family.
In some ways I think a bit of a significant learning curve may not be a bad idea. There needs to be some sort of level of competance before someone starts submitting code changes. I'm desperately trying not to sound elitist here! :-) I suppose it's akin to the problem of protecting Wikis from antisocial/incompetant people.
There's some truth in this, but what I'd want to do is lower the barrier, not necessarily remove it. I do a lot of PHP work and I'm only too aware of what can happen when everybody gets to program, but I think that a continuum from "user" to "programmer" is better than a big (and widening) gap between them. After all we're not talking about letting anybody make changes to the main codebase (which would be the Wiki parallel). Sure they can submit changes, but they'd need to be audited by the project's "owner". In the case of the accounts package I'm playing with, it (by the author's admission) isn't all great code, and many of the things I'm submitting back are just tidying and fixing the code. It can work both ways - its easy to assume that the code nobody can touch is really good code because of it, but I doubt that's true in practise (FOSS wouldn't work if it were!).
On Fri, Sep 08, 2006 at 10:12:55AM +0100, Mark Rogers wrote:
cl@isbd.net wrote:
I think one of the things that can be difficult is the major difference in "shape/philosophy" between development in a Unix(ish) environment and a Windows(ish) one.
Yes, this is true, but not so much with a cross-platform OSS development where the philosophies have more in common.
I sort of realised you were somewhere 'in between', I just threw my comment in to add the the discussion really.
As I mentioned I did have the option of compiling under Linux; but when I looked at it I had exactly the same questions as under Windows (I still didn't know my way around SVN, wxWidgets, etc). I stuck with Windows mainly because I needed to test the final application under Windows, for other less enlightened folk in the family.
In some ways I think a bit of a significant learning curve may not be a bad idea. There needs to be some sort of level of competance before someone starts submitting code changes. I'm desperately trying not to sound elitist here! :-) I suppose it's akin to the problem of protecting Wikis from antisocial/incompetant people.
There's some truth in this, but what I'd want to do is lower the barrier, not necessarily remove it. I do a lot of PHP work and I'm only too aware of what can happen when everybody gets to program, but I think that a continuum from "user" to "programmer" is better than a big (and widening) gap between them.
Yes, I'll go with that!
After all we're not talking about letting
anybody make changes to the main codebase (which would be the Wiki parallel). Sure they can submit changes, but they'd need to be audited by the project's "owner". In the case of the accounts package I'm playing with, it (by the author's admission) isn't all great code, and many of the things I'm submitting back are just tidying and fixing the code. It can work both ways - its easy to assume that the code nobody can touch is really good code because of it, but I doubt that's true in practise (FOSS wouldn't work if it were!).
It's not a very popular job, tidying up code, I suspect it's rather more likely to happen with FOSS than with commercial software though. Which is another good reason for promoting FOSS.
Mark Rogers mark@quarella.co.uk wrote:
I recently decided to do precisely this (not with Qemu, but with a GPL licenced home accounts package), and I quickly realised just how much stuff I don't know (and need to know) just to get started. [...]
Well, I did also mention "have it adapted"... but is that just a hope stated by people who understand some software package(s) that isn't properly documented or easily understood? ;-)
Anyway, I still have the same problem sometimes, when meeting new ways of working or new components. Often they aren't documented and sometimes my need to get the work done means that I don't map my path in as well as I should. I'm getting better, using git (the kernel version control system, which seems to be able to work independently even if upstream uses CVS or SVN or whatever) and trying to keep my own Changelog, README and NEWS. I'm probably still not publishing them as often as I should, though, and my contributions of in-code documentation (POD, autogsdoc, mole and whatever the php one is called) are still not as frequent as they ought to be.
Version control command lines suck. If possible, either put the common commands into a Makefile (I've usually got "make download" to update to the latest version and "make check" to run git status, cvs status or whatever) or use a plugin for your editor (Emacs VC-mode seems pretty good to me).
Do you need to use version control at first? Often I start development of my extensions on the last stable release, rather than the developers' version control. I know lots of people tell you not to do that, but I find it works for me, most of the time: I don't have to worry so much about other bugs in the core between releases, but sometimes it does mean you hit a known bug and have to port your changes forwards sooner than expected. Also, if a package has got neither a working stable release or a good developer's introducts, you should be very cautious about getting involved.
When contributing a feature originally developed on a stable release, I unpack the latest development source, the stable source I started from and my modified source and use a 3-way merge tool (Emacs emerge with ancestor most often IIRC) to port my changes forward into the latest development source. Then a version control diff gives me a patch to submit.
Not sure if this is just a rant, or whether I'm asking for help somewhere. If there is a good "getting started in FOSS development" book I'd like to know about it. [...]
They're no dummies books, not free-software-specific but http://www.robson.org/gary/writing/becomeahacker.html and http://www.catb.org/~esr/faqs/hacker-howto.html may help. Beyond that, I guess questions here, IRC or the various message systems are as good as anywhere.
Beware bad advice, though. I ranted about this recently in http://mjr.towers.org.uk/blog/2006/software#bewarewebadvice and if I had a fiver for every time I saw a web app install guide that instructs users to chmod 777 (a+rwx) a directory (a bad idea 9 times out of 10), I'd be buying all the beer at ALUGs.
Learning programming well is a good idea. I think it helps if you have at least understood a bit more than 'Hello world' with at least one from each of these lists: 1. Mostly imperative: C, Perl, PHP, BASIC, ... 2. Mostly object-orientated: objC, C++, Smalltalk, Ruby, ... 3. Mostly functional: Scheme, CLisp, Elisp, Haskell, ... 4. Mostly unusual: Forth, PostScript, SQL, Tcl, ... (Note I wrote *mostly* - these days, it's almost all languages can do all styles, which is why knowing at least one of each is helpful.) http://www.levenez.com/lang/ for links.
I think the biggest problem I have as I get older is remembering that nearly all software problems are either: a. easy; or b. easy after redesigning the software; but it's not always easy to tell which is which if the documentation isn't understandable to you, and redesigning is often more work than it's worth, especially if you face flamey opposition from the present designers!
Hope that helps,
MJ Ray wrote:
Version control command lines suck. If possible, either put the common commands into a Makefile (I've usually got "make download" to update to the latest version and "make check" to run git status, cvs status or whatever) or use a plugin for your editor (Emacs VC-mode seems pretty good to me).
That sounds like a good idea (although for someone like me who doesn't normally play with my own makefiles a bash script would do too).
Do you need to use version control at first?
In this case that's the only mechanism by which the source is available. I'm sure the author would have emailed me a .zip/.tar.gz but I'd rather I learnt SVN.
They're no dummies books, not free-software-specific but http://www.robson.org/gary/writing/becomeahacker.html and http://www.catb.org/~esr/faqs/hacker-howto.html may help.
I'll take a look, thanks.
Beware bad advice, though. I ranted about this recently in http://mjr.towers.org.uk/blog/2006/software#bewarewebadvice and if I had a fiver for every time I saw a web app install guide that instructs users to chmod 777 (a+rwx) a directory (a bad idea 9 times out of 10), I'd be buying all the beer at ALUGs.
Yes, this is common even in the INSTALL instructions supplied with a web application (which I obviously ignore!).
Learning programming well is a good idea. I think it helps if you have at least understood a bit more than 'Hello world' with at least one from each of these lists:
- Mostly imperative: C, Perl, PHP, BASIC, ...
Well my C is rusty but I've written some fairly big C projects in the past. I use PHP daily, Pascal frequently, Perl I know far too little about. Did quite a bit of Sinclair and BBC BASIC but had "outgrown" them by the time I did my computing 'O' level (I used Z80 assembler for that).
Which category would you put assembly language and similar into?
- Mostly object-orientated: objC, C++, Smalltalk, Ruby, ...
C++ I used a lot in the past (mostly TurboC++ under DOS), but none of the rest of them. I did get my grounding in OOP from Bjarne Stroustrup's C++ book (I got my C from K+R too) so I understand the idea fairly well, but it still seems like overkill for so many small projects, and so many large projects start as small projects.... I think OOP is ideal for stuff like interactions with a GUI, and there I obviously use it a lot (Object Pascal, C++, VB (if I really really have no choice)).
- Mostly functional: Scheme, CLisp, Elisp, Haskell, ...
Yay, a category I've avoided! Unless Prolog fits in there?
- Mostly unusual: Forth, PostScript, SQL, Tcl, ...
Forth I tried but never had an application for (although I did play around with a Forth-based games development package for the Spectrum). PostScript I've used in some devices completely unrelated to printers and never understood why it was there. SQL is routine for me, but I should push the database far harder than I do (I'm too used to mySQL!). Tcl I've not played with but I did use Expect for a bit which is Tcl based, I believe?
I think the most interesting point (and the only reason I went through the above) is that a good proportion of the above I learnt to some degree at school, when computers were a rarity. Now that they're everywhere, how many languages does a typical GSCE candidate get exposure to these days?
I think the biggest problem I have as I get older is remembering that nearly all software problems are either: a. easy; or b. easy after redesigning the software; but it's not always easy to tell which is which if the documentation isn't understandable to you, and redesigning is often more work than it's worth, especially if you face flamey opposition from the present designers!
Also, "if it ain't broke ...". Its too easy to introduce new bugs (or break old workarounds for bugs in external code) to make a redesign a good choice in a lot of cases. There are some very good exceptions, however. Anyone here done anything around the PHP-based osCommerce or any of its derivatives? That would be my shining example of an application that's grown with a lot of help from coders with little experience or training.
Hi Mark
On Tuesday 12 September 2006 18:57, Mark Rogers wrote:
Version control command lines suck. Do you need to use version control at first?
In this case that's the only mechanism by which the source is available. I'm sure the author would have emailed me a .zip/.tar.gz but I'd rather I learnt SVN.
"svn ci" and "svn up" are pretty much all you need to get started - Nothing ugly or complex there that needs stuffing in to a makefile... I found both http://cvsbook.red-bean.com/ and http://svnbook.red-bean.com/ well worth downloading and reading - Probably less than fifty pages from both covers most of what the average person needs to know about either subject.
And even for simple little "hello world" projects, running a revision control system is worth doing - If nothing else, it gives you a bit of experience of using the stuff ;)
When you get deeper in to OSS development, autoconf & automake are also valuable tools to get to grips with.
Regards, Paul.