new pacman based distro

lucke · 2005-05-02 11:29:52

It seems the fame of Arch's baby is spreading. Rubix is another distro taking advantage of its power, after Frugalware and NND (at least those are the ones I know about, there are probably more small projects using pacman as their package manager). Moreover, Rubix philosophy seems to be a bit similar to Arch's, it could be a good alternative for people loving pacman and simplicity, but not completely happy with Arch being so bleeding edge and other stuff. Well, too early to evaluate, but it could grow to be a worthy alternative for people unhappy with some Arch features ;-)

This post ought to be merely informative, no trolling desired ;-)

phrakture · 2005-05-02 13:54:14

Interesting that they're still sticking with slackware's layout...
Seems like people love pacman... 8)

miqorz · 2005-05-02 15:06:30

Hmm.. LFS + Pacman ... Could be interesting. *g*

-Anders · 2005-05-02 16:35:04

This dosent sound half bad actually. Unlike ArchLinux this one could run om my 486 (Currently running slackware). That is.. If they make a floppy + network based install.

phrakture · 2005-05-02 16:42:51

-Anders wrote:

This dosent sound half bad actually. Unlike ArchLinux this one could run om my 486 (Currently running slackware). That is.. If they make a floppy + network based install.

it's still i686 optimized... check their "general info" pages, I think

miqorz · 2005-05-02 16:45:09

I was wondering about that too.

It says it can run on a i486 but is i686 optimized.

phrakture · 2005-05-02 16:58:42

miqorz wrote:

I was wondering about that too.
It says it can run on a i486 but is i686 optimized.

hrrrmmm... didn't notice the 486 part... I'll email them and find out 8)

darkcoder · 2005-05-02 17:08:41

miqorz wrote:

It says it can run on a i486 but is i686 optimized.

And RedHat says they run on a i386, but is 686 optimized...humm!

I always found that kind of comment nonsense. Let's analyze it. While there has not been a big differece between x86 processor (non 64bit), the optimization that each procesor brings is different from previous ones. 686 and greater provide some parallelism between operations, something the 486 or 386 do not have. So that means either the 686 optimizations make the code slower on a 486 than a real 486 optimized distribution, or it's speed sucks on a 686 or greater processor since it use only 486 instruction set, or maybe both.

lucke · 2005-05-02 17:09:35

Well, can't be sure how it's gonna evolve, but currently it looks like a nice piece of software for servers, with its emphasis on security (grsec patched kernel in the repo, SSP/PIE enabled when possible, security advisories). It will moreover probably maintain a pretty stable branch (hopefully not as 'stable' as debian :-P), with limited, but tested selection of packages. And finally it seems it should work on i486.

Looks like a pretty interesting project to me, filling the gap between Arch and e.g. Debian (some people want stable branch in Arch so badly... :-)). The thing that makes me ponder is what would make it 'based on Slackware'? Package management is solved differently, init scripts ought to be different, what else is there to Slack? Maybe except KISS philosophy, but it isn't trademarked by Slack ;-)

Ah. There's also a mention of PKGBUILDs for packages to be put in the repos, so it seems all the possibilites ABS brings shall be there as well. All of that would make it a really nice server distro, imho.

darkcoder · 2005-05-02 19:58:28

like you said, it is a project to watch. And welcome is the extra security they are putting into it. I was working on porting some of these security steps they do, and provide them as an optional repo since I'm not very happy myself with the idea of increasing the already big enought number of distributions out there.

miasma · 2005-05-03 23:33:46

Hi Guys,

I am the primary developer at Rubix and dont want to spam arch's forums, but I already had a handle here...

First of all, all the packages are compiled with -march=i486 -mtune=i686 meaning it works with 486 and has 686 optimizations that are used when available.

Second, I do not use ABS in the same way as arch since I cant justify packaging a complete modula compiler just for cvsup.

Third, aside from package management and init scripts (yeah, that is a lot), Rubix is COMPLETELY based on Slackware. Package names and contents have been meticulously crafted to match Slackware. Rubix's initial release will be based on Slackware-current, but any package rebuilds are no longer based off of the Slackware build scripts after the first build.
The OS is designed to be a drop in replacement for Slackware, all scripts, package names, build options, everything is Slackware.

I am curious about the floppy + network install you are talking about Anders. There is one big potential problem with this, that all the kernels are too big to fit on a floppy... I dont package a bunch of kernels like Slack does. If there is a demand for a small kernel for a floppy boot, I can see what I can do. Also, please elaborate on the network install, are you talking about NFS mounts, online abs repos, network booting via bootp? Send me an email, these are issues we would like to work out. ( joshua at rubix-os dot org )

Overall I think you guys have expressed the exact thing Rubix was hoping for, more focus on stability, security and reliability than Arch, but less bleeding edge.

Please, if any of you have input, we would love to hear it, but the arch forums probably are not the place, drop me an email and see if you can influence an up-and-coming distro.

Joshua

cactus · 2005-05-04 02:18:32

miasma wrote:

Second, I do not use ABS in the same way as arch since I cant justify packaging a complete modula compiler just for cvsup.

I helped rework the current cvsup package. It uses the ezm3 modula compiler, but only duing the building of the package itself (due to ezm3 nuttiness, it was unavoidable).
ezm3 is not complete by any means. It is a stripped down modula3 compiler that is only suitable for building cvsup.
Unfortunately, ezm3 doesn't work with x86_64, but for all the i?86 builds, it should be fine.

miasma · 2005-05-04 02:25:14

cactus wrote:

miasma wrote:
Second, I do not use ABS in the same way as arch since I cant justify packaging a complete modula compiler just for cvsup.
I helped rework the current cvsup package. It uses the ezm3 modula compiler, but only duing the building of the package itself (due to ezm3 nuttiness, it was unavoidable).
ezm3 is not complete by any means. It is a stripped down modula3 compiler that is only suitable for building cvsup.
Unfortunately, ezm3 doesn't work with x86_64, but for all the i?86 builds, it should be fine.

It is a bit too late for that since we use GNU Arch instead of cvs, so I guess cvsup would not be too much help ;-), still, that is very nice that you did that, I will definitly take a look and see if it is worth packaging. As you can imagine, I have a few other higher priority packages though :-)

darkcoder · 2005-05-04 18:17:27

miasma, there is a repository or ftp site where the sources you use can be found. I would like to look at the security patches you have used and see if they can be ported to arch and provided maybe as an option.

Btw, I'm not a Arch developer. I will do this on my own free time.

miasma · 2005-05-04 18:22:17

darkcoder wrote:

miasma, there is a repository or ftp site where the sources you use can be found. I would like to look at the security patches you have used and see if they can be ported to arch and provided maybe as an option.
Btw, I'm not a Arch developer. I will do this on my own free time.

The source is freely available to everyone no matter who it is

ftp://ftp.rubix-os.org/pub/rubix/rubix-current/source

Euphoric Nightmare · 2005-05-05 01:55:14

has anyone tried this distro? I'm interested to know how it behaves.

darkcoder · 2005-05-05 21:44:53

haven't tested, but probably will feel slower than arch. Btw, that comment do not have anything to do with the optimizations comment I said early. I am testing an exec-shield kernel and glibc ssp package, and system fell like 10-20 percent slower on Gnome when loading, when using the patches than where not. Maybe is not that bad, but yes is perceivable.

darkcoder · 2005-05-05 21:51:16

but again, I feel safer if the OS on my server/router includes some hardening precautions, than when not.

miasma · 2005-05-06 02:34:41

hi again,

fyi, glibc is NOT compiled with SSP, it requires major patching to do that and could break downstream packages that depend on it (and EVERYTHING depends on glibc

also, there are 3 kernel options, kernel24, kernel26 and kernel24-grsec, so you dont have to use the security enhanced kernel.

I run it on a laptop at 500MHz, 256MB RAM with KDE, not to mention encrypted, /tmp, swap and /home and it runs great.

darkcoder · 2005-05-06 03:17:55

thanks for the info.

Even while grsecurity is more complete, the heavy patching was the primary cause I decided to try exec-shield.

I only patch the kernel for exec-shield, and both glibc and gcc for ssp. And recompile some of the basic core programs (binutils, ncurses and so on). My system boots fine with either the normal Arch kernel26 or my custom exec-shield one with those components installed (and have both Gnome and KDE full loaded).

Right now I'm in the process of compiling other GNU toolchain and server packages and their dependencies of course. But haven't found any issue so far.

darkcoder · 2005-05-06 03:19:54

and is good to read that there are many kernel options. Probably will give it a test to that distro soon.

ozar · 2005-05-21 20:58:57

Euphoric Nightmare wrote:

has anyone tried this distro? I'm interested to know how it behaves.

Yeah, I'm playing with it now and it seems to run just fine so far - seems to be very stable.

It reminds me of Arch, not only because it uses Pacman, but because of the config files used. The admin has just opened up a new "community repository", too, so maybe the number of available packages will start to grow.

It's a quick install and all you need is the first CD (for net install) if you should decide to give it a try.

Anonymo · 2005-05-22 05:05:35

I am also going to try it

pwe · 2005-05-22 18:24:06

should be nice. slack+pacman, without Patt

jerem · 2005-05-22 19:21:57

should be nice. slack+pacman, without Patt

To my opinion, Patrick Volkerding is a man who maintains one of the most stable distro next only to Debian. Pat is one of Slack's best points, not a drawback...

His "no-thousand-patches", time-tested packages and his more-than-10-years experience of whole distro maintaining made Slackware one of the distro I like most.

<troll> Nothing's gonna ever challenge the "original" Slackware !!! </troll>

I like Arch and Slack, and I'm glad one had the idea and the courage to build a new distro with this strong base.

Arch Linux

#1 2005-05-02 11:29:52

new pacman based distro

#2 2005-05-02 13:54:14

Re: new pacman based distro

#3 2005-05-02 15:06:30

Re: new pacman based distro

#4 2005-05-02 16:35:04

Re: new pacman based distro

#5 2005-05-02 16:42:51

Re: new pacman based distro

#6 2005-05-02 16:45:09

Re: new pacman based distro

#7 2005-05-02 16:58:42

Re: new pacman based distro

#8 2005-05-02 17:08:41

Re: new pacman based distro

#9 2005-05-02 17:09:35

Re: new pacman based distro

#10 2005-05-02 19:58:28

Re: new pacman based distro

#11 2005-05-03 23:33:46

Re: new pacman based distro

#12 2005-05-04 02:18:32

Re: new pacman based distro

#13 2005-05-04 02:25:14

Re: new pacman based distro

#14 2005-05-04 18:17:27

Re: new pacman based distro

#15 2005-05-04 18:22:17

Re: new pacman based distro

#16 2005-05-05 01:55:14

Re: new pacman based distro

#17 2005-05-05 21:44:53

Re: new pacman based distro

#18 2005-05-05 21:51:16

Re: new pacman based distro

#19 2005-05-06 02:34:41

Re: new pacman based distro

#20 2005-05-06 03:17:55

Re: new pacman based distro

#21 2005-05-06 03:19:54

Re: new pacman based distro

#22 2005-05-21 20:58:57

Re: new pacman based distro

#23 2005-05-22 05:05:35

Re: new pacman based distro

#24 2005-05-22 18:24:06

Re: new pacman based distro

#25 2005-05-22 19:21:57

Re: new pacman based distro

Board footer