To download, compile, and install from ports, simply:
cd /usr/ports/lang/python
sudo make install
-Ross
>Hi All,
>I am looking for alternatives to my current Linux OS, and am currently
>evaluating both FreeBSD and OpenBSD.
>Has anyone got a strong point for or against one of these OSes,
>specifically regarding Python? I am especially interested in
>- the ease of compiling CPython
>- the thread support (both for Python and in general)
>- running Twisted.
I went through this recently, BSD is much nicer in many ways. I loaded both
OpenBSD and FreeBSD. FreeBSD seems easier in most respects and I've pretty
much settled on that. If only I could do the same at work and get away from
this RedHat crap :(
So, for FreeBSD: If you're network connected, keeping up to date with
ports/packages is easy, I'm still trying to find out about non network
connected machines. For python, everything seems to work as expected. I
I haven't tried twisted yet (it's on my todo list - I'll get round to it about
the same time they explain it !) but I wouldn't expect any problems.
However, if you wanted the extra security of OpenBSD, my experience was that
it was only a little extra work (sometimes none) for OpenBSD. Unless you want
the very latest versions of something, in which case you could either be in
for a wait or a lot of work.
There are definitely pros and cons on both sides though, for instance, I seem
to have a flaky motherboard that locks up my shiny new drive (see below).
OpenBSD just quietly downgraded the connection (something I didn't even know
was possible) and allowed me to carry on working, with other systems I have to
manually downgrade it in the bootup sequence.
Actually, what I did for my home PC was buy a 120Gb drive (they're pretty
cheap now - cheaper than a copy of Windows for example) and partition it into
4 holding: OpenBSD (which must be 1st), FreeBSD, Debian and a space for Hurd.
Along with RedHat 8.? on the original disk. This gives me a lot of
flexibility for trying things out in different systems. It's rare for me to
not use FreeBSD.
Cheers,
Eddie
You won't have any difference for python working under freebsd or openbsd.
Just be sure about your python version, many differnces come from a
version to another one.
I can't comment on OpenBSD, but the Python support in FreeBSD is excellent.
There was a freebsd-python mailing list, set up earlier this year, that you may find helpful:
http://lists.freebsd.org/mailman/listinfo/freebsd-python
Regards,
Graeme
--
Graeme Cross <g...@invetech.com.au>
Invetech Pty Ltd - http://www.invetech.com.au/
I've been running Python on OpenBSD for years.
It builds and runs great. I do most of my work on OpenBSD.
Threads work fine, but it's been a while since I've tested them.
I have not tried CPython or Twisted.
Also, check out NetBSD as an alternative, but OpenBSD is still my favorite.
Yours,
Noah
> I am looking for alternatives to my current Linux OS, and am currently
> evaluating both FreeBSD and OpenBSD.
> Has anyone got a strong point for or against one of these OSes,
> specifically regarding Python? I am especially interested in
> - the ease of compiling CPython
> - the thread support (both for Python and in general)
> - running Twisted.
I run OpenBSD and am more than happy with it. It's the most secure of
the BSDs and is a very clean implementation. You will find that
staying current with OpenBSD is more work than with Debian, because
they put out new releases every six months like clockwork. The whole
base system comes in one piece (with optional compilers and X) and is
guaranteed to work well as an integrated unit.
Threads are fine. I haven't tried Twisted.
Python is available as a package (binaries) and can also be built in
the ports tree (source from the OpenBSD CVS). OpenBSD is unique among
the BSDs because when you build a port it creates a package, which is
then installed and entered into the package database. That way you
have full information on what is installed on your system.
However, they do patch Python slightly by adding Modules/setup.local
to get around a non-standard naming of the tcl/tk libraries.
I've made a patch for Python which fixes this. It works on OpenBSD
and should work on FreeBSD, but I haven't confirmed that.
If you want to track the current Python CVS, ports won't work for you.
Just check out a copy of Python CVS, apply
and you should be able to build Python without a problem using the
tcl and tk packages from OpenBSD.
--
KBK
FYI: CPython is the C-based implementation of the interpreter.
Unless you've been running Jython, PyPi, or some other 3rd party
developed Python interpreter, you're running CPython.
- Josiah
Twisted has a FreeBSD buildslave in its buildbot:
http://twistedmatrix.com/buildbot/
As you can see, all but one of the 1214 tests are passing. (Help with
figuring out how to fix it would be welcome, though!).
-Andrew.
>However, they do patch Python slightly by adding Modules/setup.local
>to get around a non-standard naming of the tcl/tk libraries.
That is what worries me with OpenBSD. They patch everything in order to
make things more secure, which is their main focus. But doesn't this
bring a lot of compatibility issues along?
If you compile "plain" Python from www.python.org with the patched gcc,
who guarantees that it will work?
If you installed a patched Python, how can you be certain no bugs have
been added?
In any case, you're running a configuration that's less tested than the
"original".
Unique? Of course not. FreeBSD does so. I'll be very surprised if NetBSD
doesn't.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
This surprises me a bit. I know the sysadmins of my NetBSD shell
provider have had perennial difficulty compiling Python with threads
enabled. Is there anyone who uses Python with threads on NetBSD?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"usenet imitates usenet" --Darkhawk
> That is what worries me with OpenBSD. They patch everything in order to
> make things more secure, which is their main focus. But doesn't this
> bring a lot of compatibility issues along?
The patching to Python is minimal. They don't patch "everything". The
base system is audited and unique to OpenBSD but the ports are not.
Many patches are like the one I mentioned: needed to resolve issues
like an incompatibility in the directory tree or libraries.
I agree that the goal is to use the minimum patch necessary to get the
port to work, and then to push whatever possible back upstream so it
can be eliminated in the future. The distros are the field test for
the applications, and it's common for the patches to be applied there
first. But the more patches you have, the harder it is to maintain.
If OpenBSD should patch a security issue in the port, wouldn't you
think that the upstream maintainer would want to incorporate it? When
he does, the patch is no longer required. If he doesn't, wouldn't you
want the hole fixed in the distro?
> If you compile "plain" Python from www.python.org with the patched
> gcc, who guarantees that it will work? If you installed a patched
> Python, how can you be certain no bugs have been added? In any
> case, you're running a configuration that's less tested than the
> "original".
This is true with all distros. Have you ever looked at the patches
applied by RedHat and Debian? Have you ever studied the Debian
patches to the Linux kernel? OpenBSD is hardly the worst.
In many cases the patches applied by the distros are caused by
unresponsive upstream maintainers and/or delays in implementing the
patches fed upstream.
If you don't like the situation, something like Linux from Scratch is
alway an option, but I think you will find that you will be patching the
pristine sources to get a working system :-)
It's the packagers who have the responsibility to make the package
work. Packagers are carefully screened by responsible distros.
--
KBK
> Unique? Of course not. FreeBSD does so. I'll be very surprised if NetBSD
> doesn't.
AFAIK, FreeBSD doesn't actually produce a package file. But you are
correct, it does make an entry into the database.
--
KBK
I missed that, did he say threads are fine on NetBSD? NetBSD is one
of the last holdouts on system level threads, so until NetBSD 2.0,
you need a `green' thread package like pth. I've seen that work, in
a network service daemon application, but my sympathies to the sysadmins
who've wasted time trying to get it to work in Python. Shell provider
that runs NetBSD? Interesting.
FreeBSD does have threads. Implementation changed radically between
v 4 and v 5, if I remember right.
Donn Cave, do...@drizzle.com
If by package file you mean a .tgz which you can copy to another machine
and then apply "pkg_add" to, this is created by the target "make package".
Maybe not many differences on these points. But I can introduce
difference of features between FreeBSD and OpenBSD ports. (I'm
slightly biased. sorry :)
FreeBSD ports OpenBSD ports
Versions 1.5.2, 2.0.1, 2.1.3, 1.5.2, 2.1.3, 2.2.3,
2.2.3, 2.3.3, 2.4 (040311) 2.3.3
Backported - email.Charset fix for cjkcodecs none
patches (2.3) - intobject.c 2.105 allocation fix
- weakrefobject.c 1.13.6.1 gc fix
Unicode UCS4 UCS2
IPv6 enabled enabled
Threads enabled enabled
Shared lib. both (PIC shared, non-PIC static) non-PIC static only
# of ports 197 50
starting with
py-
FreeBSD's port tweaked many options from the original. So if you
prefer the vanilla python, you'd better to install from the source
tarball. But you can use a port as it is if you do it in OpenBSD
then.
Regards,
Hye-Shik
I've noticed that OpenBSD has a current and stable ports version. If you
stick with stable, you may wait for a bit for the ports maintainer to
upgrade to the next version.
Also, if you didn't install X11 when you installed OpenBSD and you try to
install Python from ports, it tries to install tcl, which tries to
eventually install X11. You need to use 'flavors' to install a non-GUI
python version.
>However, they do patch Python slightly by adding Modules/setup.local
>to get around a non-standard naming of the tcl/tk libraries.
That is what worries me with OpenBSD. They patch everything in order to
make things more secure, which is their main focus. But doesn't this
bring a lot of compatibility issues along?
If you compile "plain" Python from www.python.org with the patched gcc,
who guarantees that it will work?
If you installed a patched Python, how can you be certain no bugs have
been added?
In any case, you're running a configuration that's less tested than the
"original".
The reason for the patching is not security but compatability. In fact they
explicitly warn you that external packages do not go through the security
audit. The patches are to cover any differences between BSD and the intended
target Unix (eg change Linuxisms to BSDisms). In other words compiling plain
Python won't work.
Eddie