Best Linux distro for GNUstep?
Dario Niedermann
GNUstep?
Feel free to use your own definition of "best"...
TIA
--
> head -n1 /etc/*-{version,release} && uname -moprs
Slackware 12.2.0
Linux 2.6.27.31-smp i686 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
Stefan Bidi
_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
David Chisnall
> What's the best Linux distribution for installing, setting up and using
> GNUstep?
If you want to install from source, pretty much anything works. I now quite a few people use Debian or Ubuntu. Richard uses Centos, as I recall, but I wouldn't recommend that because its ancient glibc is even horrible to work with than recent glibc.
If you want decent packages, skip Linux and use FreeBSD - ports show up a few days after each release and then it's just a matter of 'portinstall gnustep' to get all of the dependencies and everything installed. Oh, and you also get some nice bonuses like ZFS and sound that works without buggy userspace sound daemons.
David
Csanyi Pal
> I've used it with Debian, Slackware and even Ubuntu. Assuming you'll
> be installing from source, none is by any means better than the
> other. You just have to make sure you install all the
> dependencies... in Slackware, for example, you might need to go to
> slackbuilds.org for a few of them.
I have just try to install GNUstep using SVN on Debian Squeeze without
any success. See the recent threade about this in this mailing list.
--
Regards, Paul
<http://csanyi-pal.info>
Csanyi Pal
> On 23 Mar 2011, at 19:13, Dario Niedermann wrote:
>
>> What's the best Linux distribution for installing, setting up and using
>> GNUstep?
> If you want decent packages, skip Linux and use FreeBSD - ports show
> up a few days after each release and then it's just a matter of
> 'portinstall gnustep' to get all of the dependencies and everything
> installed. Oh, and you also get some nice bonuses like ZFS and sound
> that works without buggy userspace sound daemons.
It sounds good. Maybe it's time to change my distro from Debian to
FreeBSD?
Sebastian Reitenbach
> It sounds good. Maybe it's time to change my distro from Debian to
> FreeBSD?
after a relase of some gnustep related software. If someone misses sth. there,
let me know, it can be added ;)
Sebastian
Martin Dietze
> If you want decent packages, skip Linux and use FreeBSD - ports show up
> a few days after each release and then it's just a matter of 'portinstall
> gnustep' to get all of the dependencies and everything installed. Oh,
> and you also get some nice bonuses like ZFS and sound that works without
> buggy userspace sound daemons.
Now there's always a bit of a conflict between having the most
recent GS code *OR* having a distro on which every GS-based
application will always work.
While using quite a few GS apps on my desktop installing a new
GS version from the sources can mean having to recompile those
apps, too. Using the apps from my distro does not really help
because I can't be sure that my self-compiled bleeding-edge GS
coexists with my distro's one.
This is why I've surrendered and am now just using my distro's
(old) GS packages - which basically means *NO* Etoile stuff.
So what would be really useful for proper distro integration
would be not only providing packages of the GS libraries but
also the whole suite of GS-based applications built against the
most recent version of the libraries. Coming from the Debian
world I'd see this kind of approach as an "experimental" and
unofficial apt repository.
I don't know how the *BSD-guys do it, if 'portinstall gnustep'
does all the stuff I'm talking about then this looks fairly
attractive and probably means that they've got small upgrade
cycles for packages and also an enthusiastic package maintainer
who even has an eye at all the applications out there.
However for most distros this is not the case. And given the
fact that there are rather frequent changes in the GS libraries
ordinary distro users will only see the older GS-apps for a long
time until sometime in the future there is a major release of
the Etoile code.
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
Wer bist du, ungezaehltes Frauenzimmer? Du bist - bist du? - Die Leute sagen,
du waerest - lass sie sagen, sie wissen nicht, wie der Kirchturm steht.
David Chisnall
> I don't know how the *BSD-guys do it, if 'portinstall gnustep'
> does all the stuff I'm talking about then this looks fairly
> attractive and probably means that they've got small upgrade
> cycles for packages and also an enthusiastic package maintainer
> who even has an eye at all the applications out there.
FreeBSD lets you update third-party packages independently of the core OS. This seems much more sane than the approach of most Linux distributions, where they try to make third-party packages conform to the distribution's release cycle, but I suppose that's required since everything in a Linux distribution is a third-party package.
Dirk Meyer does a really good job of keeping GNUstep ports (used to build packages on FreeBSD) up to date, so you can typically just update your installed packages and get the latest versions of stuff.
The gnustep port is a metaport, which just depends on a load of GNUstep stuff. When you run this command, it grabs the latest versions and compiles them. You can add -P to grab the binary packages if you prefer, although this won't work for anything that's GPLv3 or has a license that prohibits binary distribution. Since the GNUstep tools are now GPLv3, we no longer have pre-built binaries for FreeBSD, so you need to build from ports.
David
-- Sent from my STANTEC-ZEBRA
Ivan Vučica
On 24 Mar 2011, at 15:51, Martin Dietze wrote:
FreeBSD lets you update third-party packages independently of the core OS. This seems much more sane than the approach of most Linux distributions, where they try to make third-party packages conform to the distribution's release cycle, but I suppose that's required since everything in a Linux distribution is a third-party package.
Dirk Meyer does a really good job of keeping GNUstep ports (used to build packages on FreeBSD) up to date, so you can typically just update your installed packages and get the latest versions of stuff.
The gnustep port is a metaport, which just depends on a load of GNUstep stuff. When you run this command, it grabs the latest versions and compiles them. You can add -P to grab the binary packages if you prefer, although this won't work for anything that's GPLv3 or has a license that prohibits binary distribution. Since the GNUstep tools are now GPLv3, we no longer have pre-built binaries for FreeBSD, so you need to build from ports.
Regards,
Ivan Vučica
David Chisnall
> On Thu, Mar 24, 2011 at 18:42, David Chisnall <ther...@sucs.org> wrote:
> On 24 Mar 2011, at 15:51, Martin Dietze wrote:
>
>> FreeBSD lets you update third-party packages independently of the core OS. This seems much more sane than the approach of most Linux distributions, where they try to make third-party packages conform to the distribution's release cycle, but I suppose that's required since everything in a Linux distribution is a third-party package.
>>
> I can install third-party .debs on Debian and Ubuntu whenever I want, and add third party repositories. In fact, as you know, Debian has unstable and testing, and even experimental. Dependency checks can cause issues, but so they can on FreeBSD, right?
You misunderstand. When I say 'third-party packages' I mean 'software not written / maintained by the FreeBSD team'. This means everything except the FreeBSD kernel, core useland apps, and a few things that are essential to a working system, which the FreeBSD team maintains forks of.
In the Linux world, almost nothing is actually written by the distribution authors. The kernel comes from Linux, the core userland comes from the GNU project, and so on. In Debian, for example, there is no distinction between things like GIMP and thinks like the Linux kernel - they are both provided via the same mechanism. In the BSD world, there is a core system and there are third-party packages. You can update packages independently of the base system, and are encouraged to do so (except on OpenBSD). This means that you can start using third-party things as soon as they are ready.
I think Fedora still has a similar model, where packages are made available as soon as they are ready upstream, but Debian (and, by extension, Ubuntu) ships a huge raft of third-party programs as a single snapshot of the state of the software world, and you then use those versions until a new version of the core OS is released. Of you install packages from a source other than the official repositories.
David
Martin Dietze
> In the Linux world, almost nothing is actually written by the
> distribution authors. The kernel comes from Linux, the core userland
> comes from the GNU project, and so on. In Debian, for example, there is
> no distinction between things like GIMP and thinks like the Linux kernel -
> they are both provided via the same mechanism.
This is true - in principle. However on Debian-based systems we
can use several repositories from which we install software. For
example, we have debian-multimedia.org from which we obtain
multimedia stuff more recent than what comes with the
distribution. (the same is now possible on RPM-based systems,
too, if you use tools like yum)
In my previous post I wrote:
> So what would be really useful for proper distro integration
> would be not only providing packages of the GS libraries but
> also the whole suite of GS-based applications built against the
> most recent version of the libraries. Coming from the Debian
> world I'd see this kind of approach as an "experimental" and
> unofficial apt repository.
This implies that *in principle* providing this kind of service
is absolutely possible - setting up an apt (and/or yum)
repository for GNUstep in which more recent replacements for the
packages provided by the distros are provided. The problem here
is that there are subtle differences between the ways those
packages are packaged on different distros, even on Debian and
Ubuntu they are usually not the same.
This is all possible, but somebody has to do the work. I think
it would be a good start to establish a convention to maintain
distro-specific code like the `debian/' subdirectory or .spec
files in the source repositories (this would apply ideally bo
both GNUstep and GS-based apps). That would make maintenance
easier for third-party maintainers (who may but not need to be
the respective distro's maintainer for the GS packages).
At the moment we're still far from all this. And as long as we
don't improve (i.e. make access to recent ready-built packages
for distro users easy and seamless) acceptance is likely to
remain low.
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
I am not in a hurry. I prefer to cross the town.
Christopher Armstrong
Ubuntu allows sort of "personal" repositories as well, which we can
control the release cycle of. These are often used for things like
themes and software that has alot of release cycles e.g. I used it
yesterday for backintime (a backup programme) because the Ubuntu 10.04
version was buggy.
I think it might be possible for us to use one of these, at least for
Ubuntu users, as we could maintain more up-to-date packages for users
interested in trying up-to-date versions of GNUstep. The only problem I
see is that the maintainer of the PPA needs to sign the Ubuntu Code of
Conduct.
https://help.launchpad.net/Packaging/PPA
Cheers
Chris
--
Christopher Armstrong
carmstrong ^^AT^ fastmail dOT com /Dot/ au
Philippe Roussel
> Ubuntu allows sort of "personal" repositories as well, which we can
> control the release cycle of. These are often used for things like
> themes and software that has alot of release cycles e.g. I used it
> yesterday for backintime (a backup programme) because the Ubuntu 10.04
> version was buggy.
>
> I think it might be possible for us to use one of these, at least for
> Ubuntu users, as we could maintain more up-to-date packages for users
> interested in trying up-to-date versions of GNUstep. The only problem I
> see is that the maintainer of the PPA needs to sign the Ubuntu Code of
> Conduct.
I already did that for whatever reason so if somebody is willing to
creating the source packages, I could create a PPA.
At what rate those packages would be updated ?
Philippe
Dario Niedermann
> If you want decent packages, skip Linux and use FreeBSD
I'd really love to, if only FreeBSD supported my graphics card and ACPI
suspend/resume.
However, if Slackware is GNUstep-friendly and other distros don't offer
significant advantages with regard to GNUstep, I think I'll stick with
Slackware, which I rather like.
Thanks to all respondents!
Christopher Armstrong
On Thu, 24 Mar 2011 23:55 +0100, "Philippe Roussel"
<p.o.r...@free.fr> wrote:
> Le vendredi 25 mars 2011 à 09:22 +1100, Christopher Armstrong a écrit :
> > ....
> >
> > I think it might be possible for us to use one of these, at least for
> > Ubuntu users, as we could maintain more up-to-date packages for users
> > interested in trying up-to-date versions of GNUstep. The only problem I
> > see is that the maintainer of the PPA needs to sign the Ubuntu Code of
> > Conduct.
>
> I already did that for whatever reason so if somebody is willing to
> creating the source packages, I could create a PPA.
>
> At what rate those packages would be updated ?
I think they should be updated every time we make a new release of
GNUstep. Any less frequently defeats the purpose, and we don't have the
resources to stabilise out-of-cycle releases of the trunk repository any
more frequently than the release cycle we have.
We could also possibly provide automatic "snapshot" releases of the
trunk repository on a daily basis for people who quickly need an
unstable version to check a bug fix. I don't think we should support
this option, unless it really helps those people who quickly want to get
an unstable version running on their system.
Martin Dietze
> We could also possibly provide automatic "snapshot" releases of the
> trunk repository on a daily basis for people who quickly need an
> unstable version to check a bug fix. I don't think we should support
> this option, unless it really helps those people who quickly want to get
> an unstable version running on their system.
Usually it's a good approach to check for new tags on a
particular branch. As soon as developers think a version is
stable enough to be considered better than 'experimental' they
just tag the code and the automatic build creates new packages
next night.
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
In an organization, each person rises to the level of his own incompetency.
-- The Peter Principle
Ivan Vučica
self hosted repo is trivial even without Ubuntu's infrastructure, as
soon as you have the .deb files ready.
Regards,
Ivan Vučica
via phone
On 24. ožu. 2011., at 23:55, Philippe Roussel <p.o.r...@free.fr>
wrote:
> Le vendredi 25 mars 2011 à 09:22 +1100, Christopher Armstrong a écri
> t :
>> Ubuntu allows sort of "personal" repositories as well, which we can
>> control the release cycle of. These are often used for things like
>> themes and software that has alot of release cycles e.g. I used it
>> yesterday for backintime (a backup programme) because the Ubuntu
>> 10.04
>> version was buggy.
>>
>> I think it might be possible for us to use one of these, at least for
>> Ubuntu users, as we could maintain more up-to-date packages for users
>> interested in trying up-to-date versions of GNUstep. The only
>> problem I
>> see is that the maintainer of the PPA needs to sign the Ubuntu Code
>> of
>> Conduct.
>
> I already did that for whatever reason so if somebody is willing to
> creating the source packages, I could create a PPA.
>
> At what rate those packages would be updated ?
>
> Philippe
Martin Dietze
> From my experience as a multiyear Debian user, with Debian, packages are
> also released as soon as they are ready. Person switches to "unstable"
> and that's it. One can also use "experimental" for individual bleeding
> edge packages. But, "unstable" is just that -- unstable.
I, like many other Debian users, usually run on 'testing'.
The package policy is still pretty conservative, i.e. there's
hardly any bleeding-edge stuff. Now I can install some
particular packages from 'unstable', selectively. This often
does not work since they may depend on other stuff which is not
available on 'testing' (there were times when some of the base
libraries were available in incompatible versions on 'testing'
and 'unstable'). Also sometimes packager change some of the
structure from 'unstable' to 'testing', i.e. a library package
is split into several smaller ones etc. This makes running a
large set of libraries and applications like the GS suite
installed from 'unstable' on a 'testing' system unfeasable. Even
if it works, you need quite a bit of expertise to install it.
Thus I see no alternative to providing packages for the
different distros on a central repository. With the current
approach on Linux we're stuck on either running outdated
versions provided by our distros or compiling GS and all that
depends on it by hand. After having done the second for years
and having invested far too much time in updating sources,
compiling them, finding things not working etc., I've switched
back to the first approach which means no GS playtime for me.
Projects like Etoile introduce some quite attractive stuff based
on GS. But since it usually depends on the very latest GS
library code and for the reasons I described above it is de
facto not available to 95% of all Linux users. Even if only a
smaller part is 'desktop-ready' this means that GS as a platform
gets far less attention than it deserves.
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
* Free Speech Online!!! Support the Blue Ribbon Campaign! *
Csanyi Pal
I'm a Debian user too since 6 years.
I agree with everything abowe.
For me the only solution is to use FreeBSD because I want develope using
GNUstep, however I wish that that Debian change somehow so one can use
GNUstep and Étoilé on Debian with recent software.
Philippe Roussel
Le vendredi 25 mars 2011 à 15:32 +1100, Christopher Armstrong a écrit :
> Hi Phillippe
>
> On Thu, 24 Mar 2011 23:55 +0100, "Philippe Roussel"
> <p.o.r...@free.fr> wrote:
> > Le vendredi 25 mars 2011 à 09:22 +1100, Christopher Armstrong a écrit :
> > > ....
> > >
> > > I think it might be possible for us to use one of these, at least for
> > > Ubuntu users, as we could maintain more up-to-date packages for users
> > > interested in trying up-to-date versions of GNUstep. The only problem I
> > > see is that the maintainer of the PPA needs to sign the Ubuntu Code of
> > > Conduct.
> >
> > I already did that for whatever reason so if somebody is willing to
> > creating the source packages, I could create a PPA.
> >
> > At what rate those packages would be updated ?
>
> I think they should be updated every time we make a new release of
> GNUstep. Any less frequently defeats the purpose, and we don't have the
> resources to stabilise out-of-cycle releases of the trunk repository any
> more frequently than the release cycle we have.
>
> We could also possibly provide automatic "snapshot" releases of the
> trunk repository on a daily basis for people who quickly need an
> unstable version to check a bug fix. I don't think we should support
> this option, unless it really helps those people who quickly want to get
> an unstable version running on their system.
Agreed.
So the main task for producing those packages would be to create a .deb
description for each one, right ? Debian and Ubuntu already did that (or
maybe only Debian did, I don't know), we should be able to use that,
right ?
Philippe
Philippe Roussel
> Agreed.
>
> So the main task for producing those packages would be to create a .deb
> description for each one, right ? Debian and Ubuntu already did that (or
> maybe only Debian did, I don't know), we should be able to use that,
> right ?
Right ?!
Sorry about those badly written emails...
Philippe
Martin Dietze
> So the main task for producing those packages would be to create a .deb
> description for each one, right ? Debian and Ubuntu already did that (or
> maybe only Debian did, I don't know), we should be able to use that,
> right ?
Ideally the debianisation code should be moved into the source
revision control of the software whenever possible, not only for
the GS libs but also for applications based on GS. If those
packages are still maintained from my experience developers will
not object getting that 'debian/' directory from somewhere and
keeping it in the source tree, probably accepting some patches
every now and then. We've been using this approach quite
successfully with Carlos Mafra and his git repo for WindowMaker
(from which I auto-build new .deb packages whenever there are
new revisions in the git).
Ideally again this approach would have the debianisation
from the sources leading the way for distro maintainers.
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
Man muss das Dreibein hin und wieder loben, dann geht es auch schonmal runter,
den Muell wegbringen.
Riccardo Mottola
Dario Niedermann wrote:
> What's the best Linux distribution for installing, setting up and using
> GNUstep?
>
> Feel free to use your own definition of "best"...
>
If you plan to install debian by compiling it from sources, many
distirbution are convenient. Most offer the required packages and
compiler. Debian, SuSE, Gentoo, Fedora will work fine because I tested
them. I personally use Debian and Gentoo daily (well, as linux, I prefer
BSD).
If you intend to use the ready packages, things are trickier. Personaly
I wouldn't recommend Debian: I don't agree how their packages are set
up, several apps are missing and the update cycle is slow. However what
is there works, I extra have a test machine for that. Gentoo uses to be
quite good, your mileage may vary.
FreeBSD has good packages, but it is not linux :)
Riccardo
Christopher Armstrong
Hi Phillippe
----- Original message -----
> Le samedi 26 mars 2011 à 09:47 +0100, Philippe Roussel a écrit :
> > So the main task for producing those packages would be to create a .deb
> > description for each one, right ? Debian and Ubuntu already did that
> > (or maybe only Debian did, I don't know), we should be able to use
> > that, right ?
Definitely. With the PPA, they compile the source code package along with a diff that contains the debian stuff and put it in a repository for each recent release. We may need to tweak a little, but the configuration used by Ubuntu or Debian should be mostly right.
Cheers
Chris