hemant:
NOO _never_ install rubygems from apt tree, its broken.
Why not? I’m using them with great success. They land in /var/lib/gems,
I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.
-- Shot
--
design, n.: What you regret not doing later on.
M. Edward (Ed) Borasky wrote:
One other note: most Linux distros now include something called "mono".
I don't know the details, since I'm not a .NET person, but it is an open
source ".NET-like" platform of some sort.
http://www.mono-project.com/Start
http://www.mono-project.com/Main_Page
From http://www.mono-project.com/FAQ:_General
What is Mono™ exactly?
The Mono Project is an open development initiative sponsored by Novell to develop an open source, UNIX version of the Microsoft .NET development platform. Its objective is to enable UNIX developers to build and deploy cross-platform .NET Applications. The project implements various technologies developed by Microsoft that have now been submitted to the ECMA for standardization.
Mono is also available for windows, Mac OS X, Sun Solaris, BSD - OpenBSD, FreeBSD, NetBSD
I've minimal experience with mono ( recently threw together a console app to communicate with PostgreSQL ) ( the resultant app is executable on both linux and windows ). I've played around with the IDE's Monodevelop on linux and sharpdevelop on windows.
No . . . the "real source code action" would be in a BSD Unix (FreeBSD,
NetBSD, OpenBSD), not any Linux distribution. You can also get good
package-based software management, at least with FreeBSD and NetBSD (I'm
not familiar enough with OpenBSD to comment on it in this respect), if
you want that too. Back when I was a Debianista, my response to any
recommendation to give Gentoo a try was "If I wanted to use Gentoo, I'd
use FreeBSD instead." Now, I use FreeBSD.
As for whether SourceMage or Lunar is a better source-based Linux
distribution than Gentoo -- well, I'm highly skeptical of such a claim,
but I don't have the experience with them to argue one way or the other.
On Mon, Sep 10, 2007 at 12:07:42PM +0900, Trans wrote:
On Sep 9, 6:54 pm, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:
>
> The bridge you have to cross (eventually) is whether you ever want to do
> kernel builds or recompile packages from source. RHEL and its rebuilds
> actively *discourage* rebuilding the kernel. It's too easy to trash your
> system that way. But rebuilding packages from source is easy on all the
> major distros.
>
> Or you could use Gentoo, where you *have* to recompile everything from
> source.Ah, come on! SourceMage or Lunar is where the real source code action
is at
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Thomas McCauley: "The measure of a man's real character is what he would do
if he knew he would never be found out."
Sorry for self-promotion. RubyWorks stack is trying to take care of
that problem for CentOS/RHEL.
As for development desktop, I'd say go with Ubuntu 7. It seems to be
the closest thing to a consumer-grade desktop in Linux world, which is
a good thing because you will not spend as much time as with some
other distros to make network, sound drivers and printers work.
Ubuntu doesn't compromise the benefits that you get from Linux as a
developer, either. Most important of which is speed. In my experience,
Ruby on Linux beats Ruby on Windows by a factor of 2 to 3 in practical
benchmarks (such as running automated tests for a Rails app, for
example).
On 9/9/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
What you *don't* want to do with CentOS is try to manage packages that
aren't part of the distro... That way lies madness
--
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
Some get lucky. I've had nothing but heartache using the apt tree for
Ruby. This comes up pretty often on this list. I'm kind of at the
point now where I think your should do your own build from source.
Todd
On 9/15/07, Shot (Piotr Szotkowski) <shot@hot.pl> wrote:
hemant:
> NOO _never_ install rubygems from apt tree, its broken.
Why not? I'm using them with great success. They land in /var/lib/gems,
I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.
Reid Thompson wrote:
M. Edward (Ed) Borasky wrote:
One other note: most Linux distros now include something called "mono".
I don't know the details, since I'm not a .NET person, but it is an open
source ".NET-like" platform of some sort.From Redirecting…
What is Mono™ exactly?The Mono Project is an open development initiative sponsored by Novell
to develop an open source, UNIX version of the Microsoft .NET
development platform. Its objective is to enable UNIX developers to
build and deploy cross-platform .NET Applications. The project
implements various technologies developed by Microsoft that have now
been submitted to the ECMA for standardization.Mono is also available for windows, Mac OS X, Sun Solaris, BSD -
OpenBSD, FreeBSD, NetBSDI've minimal experience with mono ( recently threw together a console
app to communicate with PostgreSQL ) ( the resultant app is executable
on both linux and windows ). I've played around with the IDE's
Monodevelop on linux and sharpdevelop on windows.
Thanks!! If my day job ever decides to make me a .NET developer, I'll
keep "mono" in mind. Till then, there's Gentoo. 
Chad Perrin wrote the following on 10.09.2007 18:46 :
No . . . the "real source code action" would be in a BSD Unix (FreeBSD,
NetBSD, OpenBSD), not any Linux distribution. You can also get good
package-based software management, at least with FreeBSD and NetBSD (I'm
not familiar enough with OpenBSD to comment on it in this respect), if
you want that too. Back when I was a Debianista, my response to any
recommendation to give Gentoo a try was "If I wanted to use Gentoo, I'd
use FreeBSD instead." Now, I use FreeBSD.
It would be nice if you actually wrote what real advantages there are to
go with *BSD instead of Gentoo or whatever. I'm actually interested
because Gentoo is my current preference for a Linux distribution but I
never had the time to play with *BSD in a meaningful way. I could write
pages about how Gentoo is very good *for me* but I don't think that
would help much...
Or am I deceived and was it simple trolling around action? It can be
quite enjoyable, but please mark it <troll> </troll> then...
Lionel.
> > The bridge you have to cross (eventually) is whether you ever want to do
> > kernel builds or recompile packages from source. RHEL and its rebuilds
> > actively *discourage* rebuilding the kernel. It's too easy to trash your
> > system that way. But rebuilding packages from source is easy on all the
> > major distros.> > Or you could use Gentoo, where you *have* to recompile everything from
> > source.> Ah, come on! SourceMage or Lunar is where the real source code action
> is atNo . . . the "real source code action" would be in a BSD Unix (FreeBSD,
NetBSD, OpenBSD), not any Linux distribution. You can also get good
package-based software management, at least with FreeBSD and NetBSD (I'm
not familiar enough with OpenBSD to comment on it in this respect), if
you want that too. Back when I was a Debianista, my response to any
recommendation to give Gentoo a try was "If I wanted to use Gentoo, I'd
use FreeBSD instead." Now, I use FreeBSD.
I never quite understood the BSD fanfare. Is it really that much
different from Linux? My attempts at installation left me
disappointed. Obviously that has nothing to do with the core OS, but
nonetheless, from an end-user perspective I just didn't see any
offsetting benefit. To me you can pretty much lump them all together
as "unix".
As for whether SourceMage or Lunar is a better source-based Linux
distribution than Gentoo -- well, I'm highly skeptical of such a claim,
but I don't have the experience with them to argue one way or the other.
Well, I was just being funny. As for which source-based distro is
better, they are all very much alike really (after all you're
compiling form source), but Gentoo has much better docs and a bigger
community, so it mostly "wins" for that reason alone.
Of course, real source code action would be LFS --which is an
interesting exercise (I've done it), but a hell of a lot of work.
T.
On Sep 10, 9:46 am, Chad Perrin <per...@apotheon.com> wrote:
On Mon, Sep 10, 2007 at 12:07:42PM +0900, Trans wrote:
> On Sep 9, 6:54 pm, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:
Todd Benson wrote:
hemant:
NOO _never_ install rubygems from apt tree, its broken.
Why not? I'm using them with great success. They land in /var/lib/gems,
I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.Some get lucky. I've had nothing but heartache using the apt tree for
Ruby. This comes up pretty often on this list. I'm kind of at the
point now where I think your should do your own build from source.Todd
It's probably *better* with Gentoo than most other distros and it's
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you're right ... if you
want to run a bleeding edge Ruby and gems, you should nuke whatever's on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.
I went through this with R on CentOS 5. It's a big hassle. R is in good
shape on Debian, but only because there's a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn't need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.
On 9/15/07, Shot (Piotr Szotkowski) <shot@hot.pl> wrote:
M. Edward (Ed) Borasky wrote:
Thanks!! If my day job ever decides to make me a .NET developer, I'll
keep "mono" in mind. Till then, there's Gentoo.
I was running gentoo on a 700 mhz laptop til it died a couple of weeks ago. I get a new PC at work tomorrow - dell 9200, dual core, 64bit, blah, blah. Trying to decide whether to put straight gentoo or sabayon on it ( current work pc is ubuntu feisty ). Have you ever looked at sabayon? http://www.sabayonlinux.org/
Trans wrote the following on 10.09.2007 19:40 :
As for whether SourceMage or Lunar is a better source-based Linux
distribution than Gentoo -- well, I'm highly skeptical of such a claim,
but I don't have the experience with them to argue one way or the other.
Well, I was just being funny. As for which source-based distro is
better, they are all very much alike really (after all you're
compiling form source), but Gentoo has much better docs and a bigger
community, so it mostly "wins" for that reason alone.
IMHO (even if I consider the docs really important) what defines a
distribution is its package manager. I don't know much about Lunar and
SourceMage (I find the terminology for this one entertaining though :
spells, casting, dispelling 
) and so can't compare them to Gentoo
(I'll let people with practical experience from both Gentoo and them
compare them, especially for gems handling by the distribution's
package manager). It's though to make gems handling simpler than
Gentoo's though, on average I've only 4 to 6 lines to edit in a 20 lines
short template to package a new gem...
I was under the impression that Gentoo tried to get the best from
several packaging systems, including the port system so I'm curious
about what *BSD can bring to a Gentoo admin/user and especially one
having to deal with Ruby gems on a daily basis.
Lionel.
>
> > > The bridge you have to cross (eventually) is whether you ever want to do
> > > kernel builds or recompile packages from source. RHEL and its rebuilds
> > > actively *discourage* rebuilding the kernel. It's too easy to trash your
> > > system that way. But rebuilding packages from source is easy on all the
> > > major distros.
>
> > > Or you could use Gentoo, where you *have* to recompile everything from
> > > source.
>
> > Ah, come on! SourceMage or Lunar is where the real source code action
> > is at
>
> No . . . the "real source code action" would be in a BSD Unix (FreeBSD,
> NetBSD, OpenBSD), not any Linux distribution. You can also get good
> package-based software management, at least with FreeBSD and NetBSD (I'm
> not familiar enough with OpenBSD to comment on it in this respect), if
> you want that too. Back when I was a Debianista, my response to any
> recommendation to give Gentoo a try was "If I wanted to use Gentoo, I'd
> use FreeBSD instead." Now, I use FreeBSD.I never quite understood the BSD fanfare. Is it really that much
different from Linux? My attempts at installation left me
disappointed. Obviously that has nothing to do with the core OS, but
nonetheless, from an end-user perspective I just didn't see any
offsetting benefit. To me you can pretty much lump them all together
as "unix".
There are distinct differences between BSD Unix and Linux based OSes, not
only under the hood but in the way the system is put together from a
sysadmin's perspective. This is sorta the canonical "here are the
differences" essay:
. . . in a manner similar to the way this is the canonical "here are the
differences" essay for people coming to Linux from MS Windows:
While I do not 100% agree with everything in either of those essays, they
raise some excellent points and are in general very worth the read.
Much has been made of the "integration" difference between Linux-based
OSes and BSD Unix-based OSes over the years. Back when I was a dedicated
Debianista, I tended to mostly ignore such comments, thinking "How much
difference could that really make, anyway?" I justified my laziness
about giving a BSD Unix OS a more thorough chance than I already had in
part by reasoning that integration as discussed by BSD Unix advocates is
obviously not all it's cracked up to be -- judging by the results of
greater "integration" in the MS Windows and Apple MacOS X worlds, and
even with what closed source, proprietary UNIX systems I'd encountered.
Since starting to use FreeBSD more, however, I began to get a more
complete feel for what was meant by that "integration". It means things
work together more predictably and reliably. It means the same skills I
develop in one task area more easily transfer to other task areas. It
means that there isn't the huge gulf in configuration interfaces between
wired and wireless networking I'd come to expect when working with Linux.
It means that custom kernel configuration is much easier to learn and
manage. It means that there's more complete, cohesive, and clear
documentation, because the documentation reflects the design of the
system. It means a whole lot more than that, too, and I could probably
go on for hours.
I'm not saying a BSD Unix system is necessarily better than a Linux
distribution in all cases. There are instances where I would choose a
Linux system over a BSD Unix system for purposes of technical
capabilities (such as clustered computing -- though it appears some BSD
Unix projects are catching up).
Obviously, the difference between BSD Unix and Linux distributions is
generally not as great as that between Linux distributions and MS
Windows. They're much more alike than different, as measured against the
Microsoft backdrop. There are differences, however, that to the
experienced unix-like system administrator are like night and day. It is
in large part those differences that make me prefer FreeBSD (the BSD Unix
operating system I've used the most) over Debian (the Linux-based
operating system that is, by far, my favorite Linux distribution).
> As for whether SourceMage or Lunar is a better source-based Linux
> distribution than Gentoo -- well, I'm highly skeptical of such a claim,
> but I don't have the experience with them to argue one way or the other.Well, I was just being funny. As for which source-based distro is
better, they are all very much alike really (after all you're
compiling form source), but Gentoo has much better docs and a bigger
community, so it mostly "wins" for that reason alone.
It sounds like the reality is probably pretty close to what I would have
guessed (but, as indicated, would not by any stretch have claimed to
*know* with any certainty). Gentoo definitely has some nice advantages
to it, among Linux distributions.
Of course, real source code action would be LFS --which is an
interesting exercise (I've done it), but a hell of a lot of work.
No kidding. If you're interested in a more Debian-ish philosophy on
system construction, you might also want to give DFS (Debian From
Scratch) a try. It, too, is an "interesting" exercise all its own.
On Tue, Sep 11, 2007 at 02:40:04AM +0900, Trans wrote:
On Sep 10, 9:46 am, Chad Perrin <per...@apotheon.com> wrote:
> On Mon, Sep 10, 2007 at 12:07:42PM +0900, Trans wrote:
> > On Sep 9, 6:54 pm, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Baltasar Gracian: "A wise man gets more from his enemies than a fool from
his friends."
Chad Perrin wrote the following on 10.09.2007 18:46 :
> No . . . the "real source code action" would be in a BSD Unix (FreeBSD,
> NetBSD, OpenBSD), not any Linux distribution. You can also get good
> package-based software management, at least with FreeBSD and NetBSD (I'm
> not familiar enough with OpenBSD to comment on it in this respect), if
> you want that too. Back when I was a Debianista, my response to any
> recommendation to give Gentoo a try was "If I wanted to use Gentoo, I'd
> use FreeBSD instead." Now, I use FreeBSD.
>It would be nice if you actually wrote what real advantages there are to
go with *BSD instead of Gentoo or whatever. I'm actually interested
because Gentoo is my current preference for a Linux distribution but I
never had the time to play with *BSD in a meaningful way. I could write
pages about how Gentoo is very good *for me* but I don't think that
would help much...
FreeBSD, among other things, tends to provide far greater system
stability than Gentoo. As with a comparison with any Linux distribution,
FreeBSD also presents a far greater sense of the system as an integrated
whole than Gentoo, as well -- while not sacrificing significant
customization options (which should be fairly obvious considering it's at
heart still a source-based system). Its source-based software management
is at least as easily managed as Gentoo's, and even provides more options
for how you may choose to manage it (portupgrade, portmaster, et cetera),
but succeeds at this while still sticking closer to its "roots" in source
code compilation, as all software management within the standard Ports
system can be very simply and easily handled via make, rather than
layering the idiosyncratic emerge system over everything to achieve ease
of management.
Additionally, FreeBSD provides more extensive software archives, and the
software in those archives (in the Ports tree, specifically) is generally
more thoroughly tested (in other words, no "KDE is broken this week"
jokes). Most system and software management is more straightforward, and
while Gentoo has some of the best online documentation in the Linux
world, FreeBSD documentation is the best I've ever seen -- not only
because it covers pretty much every damned thing you can think of, but
also because it is so incredibly well organized. The FreeBSD community
may not be as extensive as what you're used to with Linux, but it is also
less scattered and fractious, which means you'll probably never notice
the difference in how extensive it is unless you're specifically looking
for a local community. Even having been ever-more heavily involved in
the more expert-oriented Linux communities in recent years, I find that
short of something like the Linux kernel hackers' community or something
along those lines, the average knowledge level of the FreeBSD community
is greater than that of the Linux communities, too.
Obviously, your mileage may vary. I speak in large part simply from
personal experience. This is how it all seems to hash out from my
perspective, however.
Or am I deceived and was it simple trolling around action? It can be
quite enjoyable, but please mark it <troll> </troll> then...
It wasn't intended as a troll. I just didn't really have the time or
inclination to write a lengthy dissertation at the time. Hopefully I've
provided a little more of the substance you wanted, now.
On Tue, Sep 11, 2007 at 01:54:42AM +0900, Lionel Bouton wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
McCloctnick the Lucid: "The first rule of magic is simple. Don't waste your
time waving your hands and hopping when a rock or a club will do."
Symlink should work for any /usr/bin/ruby issues if you install is
locally.
But, on another note, isn't there a way to install gems for Ruby that is
fairly automated but distro-independent?
On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:
Todd Benson wrote:
> On 9/15/07, Shot (Piotr Szotkowski) <shot@hot.pl> wrote:
>> hemant:
>>
>>> NOO _never_ install rubygems from apt tree, its broken.
>> Why not? I'm using them with great success. They land in /var/lib/gems,
>> I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.
>
> Some get lucky. I've had nothing but heartache using the apt tree for
> Ruby. This comes up pretty often on this list. I'm kind of at the
> point now where I think your should do your own build from source.
>
> Todd
>
>It's probably *better* with Gentoo than most other distros and it's
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you're right ... if you
want to run a bleeding edge Ruby and gems, you should nuke whatever's on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.I went through this with R on CentOS 5. It's a big hassle. R is in good
shape on Debian, but only because there's a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn't need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.
It's probably *better* with Gentoo than most other distros and it's
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you're right ... if you
want to run a bleeding edge Ruby and gems, you should nuke whatever's on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.
One of the things I like about *BSD, actually, is the tendency for
anything not in the base system to end up in /usr/local. This, combined
with the way everything is ultimately based on source distributions of
software and software management is basically built on the fundamental
tools that are available everywhere, adds up to a system that's really
easy to customize with software compiled from source and added into the
system oneself, without screwing up a package management system.
Your mileage may vary, but I've had really good luck with Perl and Ruby
modules on FreeBSD.
I went through this with R on CentOS 5. It's a big hassle. R is in good
shape on Debian, but only because there's a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn't need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.
Everything should work swimmingly on Debian (most of the time, at least),
as long as you only want the version of Ruby currently in the package
repositories and don't need gems that aren't packaged for APT. If you
want a different version of Ruby or additional gems, however, you're
better off installing in /usr/local/bin rather than /usr/bin, as you
said.
On Sun, Sep 16, 2007 at 05:03:07AM +0900, M. Edward (Ed) Borasky wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
quota by 100K; and 3) RUNS ED!!!!!!"
Reid Thompson wrote:
M. Edward (Ed) Borasky wrote:
Thanks!! If my day job ever decides to make me a .NET developer, I'll
keep "mono" in mind. Till then, there's Gentoo.I was running gentoo on a 700 mhz laptop til it died a couple of weeks
ago. I get a new PC at work tomorrow - dell 9200, dual core, 64bit,
blah, blah. Trying to decide whether to put straight gentoo or sabayon
on it ( current work pc is ubuntu feisty ). Have you ever looked at
sabayon? http://www.sabayonlinux.org/
Yeah, I've looked at Sabayon -- it's a Gentoo derivative. I'm not a big
fan of derivative distros. The big three full community distros --
Fedora, Debian and OpenSuSE -- are where I think the real action is,
with Gentoo nipping at their heels in some arenas but hopelessly out of
the running in others. For example, I can't imagine running a scientific
workstation with anything other than Gentoo or Debian, and I can't
imagine running a server on anything except CentOS/RHEL, Fedora or
Debian, although I'm sure OpenSuSE is fine for servers, as is its
commercial big brother from Novell.
Since the OP is interested in Ruby and Rails, and since Rails is a
server, I pointed him towards Fedora and CentOS because I think they're
better servers. Debian stable is also an excellent server, but there's a
lot more publicly-available information about administering the Red Hat
family than there is about Debian.
I don't think, for example, you can walk into a Barnes and Noble or
Borders and pick up a book on Debian system administration that's
current with "etch", but you can find oodles of books on Red Hat
Enterprise Linux and Fedora. Of course, if you live in Portland, you can
walk down to Powell's Technical Books and get anything.
perhaps headaches.
On Sep 10, 2007, at 1:16 PM, Lionel Bouton wrote:
Trans wrote the following on 10.09.2007 19:40 :
As for whether SourceMage or Lunar is a better source-based Linux
distribution than Gentoo -- well, I'm highly skeptical of such a claim,
but I don't have the experience with them to argue one way or the other.Well, I was just being funny. As for which source-based distro is
better, they are all very much alike really (after all you're
compiling form source), but Gentoo has much better docs and a bigger
community, so it mostly "wins" for that reason alone.IMHO (even if I consider the docs really important) what defines a
distribution is its package manager. I don't know much about Lunar and
SourceMage (I find the terminology for this one entertaining though :
spells, casting, dispelling
(I'll let people with practical experience from both Gentoo and them
compare them, especially for gems handling by the distribution's
package manager). It's though to make gems handling simpler than
Gentoo's though, on average I've only 4 to 6 lines to edit in a 20 lines
short template to package a new gem...I was under the impression that Gentoo tried to get the best from
several packaging systems, including the port system so I'm curious
about what *BSD can bring to a Gentoo admin/user and especially one
having to deal with Ruby gems on a daily basis.Lionel.
Trans wrote the following on 10.09.2007 19:40 :
>
>> As for whether SourceMage or Lunar is a better source-based Linux
>> distribution than Gentoo -- well, I'm highly skeptical of such a claim,
>> but I don't have the experience with them to argue one way or the other.
>>
>
> Well, I was just being funny. As for which source-based distro is
> better, they are all very much alike really (after all you're
> compiling form source), but Gentoo has much better docs and a bigger
> community, so it mostly "wins" for that reason alone.
>
>IMHO (even if I consider the docs really important) what defines a
distribution is its package manager. I don't know much about Lunar and
SourceMage (I find the terminology for this one entertaining though :
spells, casting, dispelling
(I'll let people with practical experience from both Gentoo and them
compare them, especially for gems handling by the distribution's
package manager). It's though to make gems handling simpler than
Gentoo's though, on average I've only 4 to 6 lines to edit in a 20 lines
short template to package a new gem...
I'd say there are really four primary aspects to separating distributions
from one another:
1. software management system (package manager, ports manager(s),
whatever)
2. installation system and procedures
3. community and maintenance policies
4. software archives and how they're managed
Hopefully the reasons I made those choices are fairly obvious. In the
past, I've overlooked the "community and maintenance policies" item when
discussing the important differences between distributions, but I've
obviously seen the error of my ways.
I was under the impression that Gentoo tried to get the best from
several packaging systems, including the port system so I'm curious
about what *BSD can bring to a Gentoo admin/user and especially one
having to deal with Ruby gems on a daily basis.
I have had zero problems with Ruby that I haven't had, either exactly or
in rough comparability of the nature of the issue, with any Linux
distribution. My experience so far is that Linux distributions tend to
want to override Ruby's preferred management systems (such as gems) a
fair bit more than FreeBSD, though there are some exceptions.
More in general than that, the big wins FreeBSD provides for me over
Gentoo are related to stability, ease of ports management, and the
benefits it grants me over Linux distributions in general (which I've
addressed elsewhere in this thread today). As I'm so fond of saying
lately, your mileage may vary.
On Tue, Sep 11, 2007 at 03:16:35AM +0900, Lionel Bouton wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
John W. Russell: "People point. Sometimes that's just easier. They also use
words. Sometimes that's just easier. For the same reasons that pointing has
not made words obsolete, there will always be command lines."
Thanks for the answer, that was an interesting reading. I've some
remarks though (maybe some things changed since the last time you tried
Gentoo).
To put it more on topic, could you describe briefly how you can
integrate gems in the package management system on *BSD? With me being
very familiar with Gentoo, the ease of integration of gems into Gentoo
was probably the biggest reasons why I switched all my servers to Gentoo...
Does it build on gems like Gentoo or do you have to write messy
Makefiles like I suspect most other Linux distributions do?
Chad Perrin wrote the following on 10.09.2007 21:12 :
FreeBSD, among other things, tends to provide far greater system
stability than Gentoo.
?!? To be more stable would probably mean repairing the hardware for me!
Currently I have 3 desktops including my parents' one (and trust me, I
don't want to travel to fix their computer...) and 7 servers running
Gentoo (my business is only 4 months old, this will grow...). I started
using it 3 years ago and never had any software stability problems (of
course I don't blindly update gcc or Apache 1.3 to Apache 2.0 without
reading the upgrading documentation beforehand, actually read the
installation notices/warnings and use a staging server for critical
stuff...).
I've some experience administering Linux (I've done it for more than 10
years now), so as you said: your mileage may vary Of course I stay
away from unstable ebuilds as much as I can and test them thoroughly if
I really have to use them on production servers.
As with a comparison with any Linux distribution,
FreeBSD also presents a far greater sense of the system as an integrated
whole than Gentoo
I'm not sure if I understand this correctly. Let me rephrase to be sure:
the FreeBSD administration is more consistant across software packages,
the base system configuration is simpler.
If I understood correctly, it may be a good thing, yes. And it probably
isn't Gentoo specific: most general purpose Linux distributions come
with roughly the same software and the same heterogeneous configuration
files too. On a positive note, I like the /etc/conf.d system in Gentoo:
it brings some consistency to this (even if it can't address all problems).
However I suppose there is some inconsistency in *BSD configuration too:
the first thing that comes to my mind is Apache configuration (which
configuration complexity could arguably be compared to the one of a
whole OS...).
, as well -- while not sacrificing significant
customization options (which should be fairly obvious considering it's at
heart still a source-based system). Its source-based software management
is at least as easily managed as Gentoo's, and even provides more options
for how you may choose to manage it (portupgrade, portmaster, et cetera),
There are alternatives to emerge (paludis for example) in Gentoo (I
suppose there's always a problem to fix for someone...).
but succeeds at this while still sticking closer to its "roots" in source
code compilation, as all software management within the standard Ports
system can be very simply and easily handled via make, rather than
layering the idiosyncratic emerge system over everything to achieve ease
of management.
That's a matter of taste: make without emerge is a definitive no-no on
my servers and a real headache on any system that I don't plan to
reinstall from scratch. In fact I don't do reinstalls anymore since I
switched to Gentoo. I went further and don't even do installs anymore
too as I keep base system images ready to detar on a partition. I found
it to be more reliable and quicker than distro-based installation
methods (of course the usual Gentoo install is painfully slow, which is
what motivated me in the first place).
Additionally, FreeBSD provides more extensive software archives,
I'm surprised to hear this, Gentoo software coverage is huge and truly
amazing if you consider the unstable part of the Portage tree.
and the
software in those archives (in the Ports tree, specifically) is generally
more thoroughly tested (in other words, no "KDE is broken this week"
jokes).
KDE broken? My parents would be on the phone in an instant (and I try
not to let their system lag too much behind the tree so they probably
used all Gentoo stable KDE versions for 18 months now).
Most system and software management is more straightforward,
That I can believe easily, there's always room to improve there.
and
while Gentoo has some of the best online documentation in the Linux
world, FreeBSD documentation is the best I've ever seen -- not only
because it covers pretty much every damned thing you can think of, but
also because it is so incredibly well organized.
The lack of organization is indeed a defect. Not big (it's not a huge
pile where you spend hours looking for something) but it definitely
could be improved.
The FreeBSD community
may not be as extensive as what you're used to with Linux, but it is also
less scattered and fractious, which means you'll probably never notice
the difference in how extensive it is unless you're specifically looking
for a local community. Even having been ever-more heavily involved in
the more expert-oriented Linux communities in recent years, I find that
short of something like the Linux kernel hackers' community or something
along those lines, the average knowledge level of the FreeBSD community
is greater than that of the Linux communities, too.
That's the problem when some technology becomes popular (don't advertize
too much if you are an elitist
Thanks again,
Lionel
From: forgottenwizard [mailto:phrexianreaper@hushmail.com]
Sent: Saturday, September 15, 2007 1:55 PM
To: ruby-talk ML
Subject: Re: What Linux distribution to choose for learning
Ruby and Rubyon Rails
[...]
> It's probably *better* with Gentoo than most other distros and it's
> probably better with Ruby than some other packages with their own
> repositories, but unless the distro (or someone outside) has put a
> significant amount of effort into integration, you're right
... if you
> want to run a bleeding edge Ruby and gems, you should nuke
whatever's on
> your distro, if anything, install everything in /usr/local
from source
> and from the gem repository, and lie to other packages
expecting to see
> /usr/bin/ruby when they install.
[...]
> Fortunately, I didn't need to load Ruby or gems on this machine. Or
> stick with production stable tested configurations from the distro.
>
>Symlink should work for any /usr/bin/ruby issues if you install is
locally.But, on another note, isn't there a way to install gems for
Ruby that is
fairly automated but distro-independent?
The only universal approach is to download the gem source, build it and
install it - that should work anywhere. Then you can install any gem
directly via "gem install", though in some cases you may need the standard
build chain, plus any libraries required.
The main problem with that approach is that pretty much all distributions do
not officially support any custom installed packages outside the packet
management system. You will either lose the official support channels (think
SuSE or RHEL) for the software, may have a harder time getting community
support or may run into difficulties when updating/upgrading as custom
compilation is outside the packet management system. This may leave behind
files in unexpected places, change directory permissions, change
dependencies or library versions etc.
That is most unfortunate as the server distributions in particular often
ship software several versions out of date for security or stability
reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
example, still has Ruby 1.8.1:
# ruby -v
ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
-----Original Message-----
On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:
#
Depending on your environment, this may be impossible to circumvent - in
shared server environments, you may not have the necessary permissions/tools
available, at work policies or SLA requirements may prohibit any custom
installations. At my job, we only use Ruby interally to the engineering
group, so we can get away with customization. If it were used in production,
we'd be using whatever the official channels provide as our SLA states
having to stay 100% within vendor supported options.
Felix