Arch GNU/KFreeBSD: A more informed opinion.

kolbycrouch · 2010-01-17 17:18:23

Ok, I know there was a thread a little while ago about this, but this is just to clear up some ignorant statements.

I'm terrible at explaining things on paper (or forums) so i'll just list the common assumtions and why the arent true.

*There is no advantage to using freebsd's kernel over linux - well not the vanilla kernel, but because the main project supporting this port ( debian ) is introducing some linuxisms into the kernel, like filesystems, so gnu/kfreebsd could support zfs, ext4, ext3 so on and so on. in lamins terms, freebsd kernel has advantages over linux, linux has advantages over freebsd, however for compat reasons, debian is adding some of these linux advantages to freebsd's kernel, like the best of both worlds. a lot of the bugs i see with arch are kernel related, having a more sane release cycle would do wonders for this.

*debian gnu/kfreebsd isnt mature - Actually its quite stable considering, ive installed it on a friends desktop, he loves it, and hes not missing anything. Gentoo/freebsd isnt mature though, but thats because they use freebsd libc and userland.

*porting is way to hard - almost nothing needs to be ported, freebsd and linux use the same binary format, all the porting of non-kernel dependent code is in libc and userland, example: gnu/kfreebsd uses linux wine packages. everything but drivers and kernel dependent apps (mkinitcpio) usually work OOTB.

*it would require too many people - not true at all, i havnt tested it, but pacman and makepkg binaries should already work, its not a matter of porting arch to kfreebsd, just replacing the debian parts with arch ones.

*freebsd's kernel is buggier - I don't know what these people are smoking, ive install both linux (arch mainly) and freebsd on many systems, freebsd is always more reliable.

Something I'm excited about is the filesystem support, makeing gnu/kfreebsd more universally compatible among unix systems, especially introducing ZFS to the gnu userland. It's already in the kernel, its just the userland tools havn't quite been ported (probably because of debians strict licensing),

Trust me guys, im not the kind of person to get so eager over something unless i knew it was reasonable to accomplish.

P.S. sorry for spelling errors, and over all bad typing etiquette.

some-guy94 · 2010-01-17 17:54:44

What I would like to see is a BSD userland on a linux kernel (BSD/Linux).

AFAIK, although freebsd is able to run most linux programs natively, that doesn't mean it's a good idea to run everything in the compatibility layer.

Nezmer · 2010-01-17 17:55:32

kolbycrouch wrote:

*porting is way to hard - almost nothing needs to be ported, freebsd and linux use the same binary format, all the porting of non-kernel dependent code is in libc and userland, example: gnu/kfreebsd uses linux wine packages. everything but drivers and kernel dependent apps (mkinitcpio) usually work OOTB.

First of all, It's not a good practise for someone to call himself informed. With relativity in mind, Humans will always have limited knowledge.

The FreeBSD kernel has a Linux-compatibility stack in the kernel. Accompanied by some Linux userspace support in the ports (coming from Fedora 10 I think), you can use some Linux binaries. Other ports depend on other Linux non-standard implementations like htop which needs linuxproc enabled in the kernel.

I never actually used FreeBSD day-to-day because I don't have the time. But I invested a good time reading about it.

The project I'd like to start/contribute to one day is pacFBSD. Pacman/makepkg repos for FreeBSD all working in /usr/local while leaving the base system As-is. No forcing of anything GNU unless It's really needed or useful. Bash is the only GNUism forced as It's used widely in pacman/makepkg. It's not only needed for building but also used in the ".install" files. The design decision I'm not decided about is to use arch-like bash-based init system in /usr/local or stick to the FreeBSD way.

kolbycrouch · 2010-01-17 18:53:40

Nezmer wrote:

kolbycrouch wrote:
*porting is way to hard - almost nothing needs to be ported, freebsd and linux use the same binary format, all the porting of non-kernel dependent code is in libc and userland, example: gnu/kfreebsd uses linux wine packages. everything but drivers and kernel dependent apps (mkinitcpio) usually work OOTB.
First of all, It's not a good practise for someone to call himself informed. With relativity in mind, Humans will always have limited knowledge.
The FreeBSD kernel has a Linux-compatibility stack in the kernel. Accompanied by some Linux userspace support in the ports (coming from Fedora 10 I think), you can use some Linux binaries. Other ports depend on other Linux non-standard implementations like htop which needs linuxproc enabled in the kernel.
I never actually used FreeBSD day-to-day because I don't have the time. But I invested a good time reading about it.
The project I'd like to start/contribute to one day is pacFBSD. Pacman/makepkg repos for FreeBSD all working in /usr/local while leaving the base system As-is. No forcing of anything GNU unless It's really needed or useful. Bash is the only GNUism forced as It's used widely in pacman/makepkg. It's not only needed for building but also used in the ".install" files. The design decision I'm not decided about is to use arch-like bash-based init system in /usr/local or stick to the FreeBSD way.

Yes I understand your first paragraph, notice I use "more informed" as in limited knowledge but i've actually used the system unlike most of the people who comment on it.

Yes FreeBSD uses linux compat.
things like /proc and alsa are linux kernel dependent, which wont work.
Maybe your missing my point.
most of the OSS apps we use ( terminal emulators, web browsers etc) aren't dependent of a specific kernel.
They are built against a specific C library and to some extent userland. GNU/KFreeBSD uses only the freebsd kernel but uses gnu's userland and c library, therefore any linux binary (eg pacman) that does not depend on the kernel (obviously you need a kernel, i mean specific one) should run with problem.

some-guy94 · 2010-01-17 19:21:39

kolbycrouch wrote:

Yes FreeBSD uses linux compat.
things like /proc and alsa are linux kernel dependent, which wont work.
Maybe your missing my point.
most of the OSS apps we use ( terminal emulators, web browsers etc) aren't dependent of a specific kernel.
They are built against a specific C library and to some extent userland. GNU/KFreeBSD uses only the freebsd kernel but uses gnu's userland and c library, therefore any linux binary (eg pacman) that does not depend on the kernel (obviously you need a kernel, i mean specific one) should run with problem.

But (afaik) you can't run and firefox built on linux glibc on a freebsd glibc. So there'll be giant mix-up of linux and bsd built libraries which won't exactly work well.

Of course you can always build everything against freebsd with a gnu userland, but that is a lot of work.

Last edited by some-guy94 (2010-01-17 19:59:23)

kolbycrouch · 2010-01-17 19:46:40

Edit: it seems they are built against freebsd-glibc, so i suppose binaries are out.
An Arch gnu/kfreebsd distro, could easily borrow the debian src packages and rebuild for i686.
apparently most "porting" to freebsd glibc is extremely trivial.

Last edited by kolbycrouch (2010-01-17 19:53:19)

Nezmer · 2010-01-17 20:28:27

kolbycrouch wrote:

Edit: it seems they are built against freebsd-glibc, so i suppose binaries are out.
An Arch gnu/kfreebsd distro, could easily borrow the debian src packages and rebuild for i686.
apparently most "porting" to freebsd glibc is extremely trivial.

What is the goal you're trying to achieve here? An Arch GNU/kFBSD port? Then go for it.

I was arguing that GNU is not really necessary IMHO. Pacman/makepkg as the most sane and simple packaging system is.

There are rare cases where the (e.g FBSD libc) wouldn't suffice like building mplayer which depends on components lacking in FBSD libc IIUC. Statically-linking binaries for those rare cases is the simple solution that should be followed IMHO.

Primoz · 2010-01-17 21:58:30

I say go for it!
I tried compiling it my self, but got lost in how exactly to do that
Anyway here's source code for debian package: http://packages.debian.org/unstable/ker … source-8.0 or this: http://packages.debian.org/source/sid/kfreebsd-8
I played with one package... But I'm starting to suspect what I've downloaded wasn't the correct stuff.

Hey if there's Arch GNU/HURD project why shouldn't there be a Arch (GNU/)BSD project? (whichever then Debian one or pure BSD)
I'll gone play with this links and see if I can succeed to compile something...

Nezmer · 2010-01-17 23:28:43

@Primoz

You might find this interesting. I didn't read it yet.

Allan · 2010-01-18 01:38:22

Is this a suggestion to start an Arch/kFreeBSD project? I really got lost there!

If it is, go for it. It is not that hard to build a freebsd8 cross-compiler. From there building a working system from scratch should be easy. pacman will probably require a patch or two (mainly to get configure recognising the target). but they will be trivial.

This is a project that I have heard lots of people suggest but no-one actually wants to implement. Unless someone steps up to take the lead, I doubt we will ever see this happening.

BTW, it has only been two weeks and Arch Hurd has a booting qemu image. So getting something off the ground is not that hard.

kolbycrouch · 2010-01-18 11:59:13

Allan wrote:

Is this a suggestion to start an Arch/kFreeBSD project? I really got lost there!
If it is, go for it. It is not that hard to build a freebsd8 cross-compiler. From there building a working system from scratch should be easy. pacman will probably require a patch or two (mainly to get configure recognising the target). but they will be trivial.
This is a project that I have heard lots of people suggest but no-one actually wants to implement. Unless someone steps up to take the lead, I doubt we will ever see this happening.
BTW, it has only been two weeks and Arch Hurd has a booting qemu image. So getting something off the ground is not that hard.

Thanks for the enthusiasm.
I would love to start the project, i have nowhere to host it , and I'll eventually need some help.
Atleast it's a reasonable idea. A lot of people where suggesting a archbsd project but that might require a lot more work considering arch is built around GNU.
I'll work on getting pacman and makepkg running first. The only thing I won't work on is mkinitcpio, AFAIK it's completely built around the linux kernel. I don't believe FreeBSD's kernel even uses initramfs.

Edit: we should see some progress as soon as I get a dedicated machine running.

Last edited by kolbycrouch (2010-01-18 12:00:28)

towelfox · 2010-01-20 18:49:25

I am not sure whether I like this idea or not. I think it would be a good idea to work *with* FreeBSD - I don't think BSD needs any more versions/distributions. I am not sure that would be well appreciated and could cause more harm than good.

As I see it, what stops me from using Freebsd is the focus on ports. Packages are seen as somewhat secondary and my experience is that they are slow to be updated. I am quite happy to build my kernel and userland but I do not want to build all my third party software as I simply do not have time.

Is it right/necessary to even port pacman? Could it be better to just create a pacman-like wrapper for the existing package tools to keep things Arch-like from the outside to make migration easier. I like our way of dealing with package management, but I think their way isn't all that bad either - They just need them to be updated more quickly.

Perhaps a good starting point would be to push the existing FreeBSD package maintainers to be faster - and help them to be faster. If packages were built and ready as quickly as they are for Archlinux you'd essentially have what I think you're looking for.

From there you'd be able to look at providing an alternative installer. You could also look at packaging the 'base' userland & kernel for binary updates between version but I think it gets more complicated.

I'd definitely like to see an Archlinux compat for BSD though.

Have you got any feedback from FreeBSD community? I think it's important.

Please let me know how you're getting on.

Cheers
Rob

apollokk · 2010-01-20 19:47:10

It would be a very good project. I could help too

Nezmer · 2010-01-20 22:49:55

towelfox wrote:

As I see it, what stops me from using Freebsd is the focus on ports. Packages are seen as somewhat secondary and my experience is that they are slow to be updated. I am quite happy to build my kernel and userland but I do not want to build all my third party software as I simply do not have time.

I agree with not all but most of what you said.
Isn't It a policy though in FreeBSD to only update packages with releases ?

Last edited by Nezmer (2010-01-20 22:50:38)

MkFly · 2010-01-20 23:53:28

I'd love to see this as well, although I would certainly continue to run Arch Linux on my desktop/workstation machines. I normally use FreeBSD for server roles, so it might see some action there.

Last edited by MkFly (2010-01-20 23:53:49)

Primoz · 2010-01-21 16:39:17

You know what I realised? There's a lot of talk but minimum of action...
I know why I don't start developing it, because I don't know where to start. What do I try and compile kFreeBSD alongside Arch, do I install it in VirtualBox and then start from there, or something completely different?
Also I have no idea what exactly to do after that. I mean I know how to compile a kernel with help of yaourt and all but this is probably completely different.
With knowledge I'd install kFreeBSD and compilers, then wget sources for pacman etc.. and try to compile them...
But I don't actually know if this would work and all.

towelfox · 2010-01-21 17:52:02

Nezmer wrote:

I agree with not all but most of what you said.
Isn't It a policy though in FreeBSD to only update packages with releases ?

Packages are built from ports which continue to to be updated between releases. These are then hosted on the FTP at packages-8-stable or packages-9-current (see ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/) for those who want to remain up-to-date.

If I understand correctly, the only restriction is when the ports are frozen before a new release is rolled out. During the Freeze nothing can be updated without permission. This is usually for a couple of weeks or so, so generally it is fine to release an upto date port/package.

- I think that building packages is what really keeps Arch maintainers busy. I would think that if there was a team dedicated to ensuring packages in Freebsd were in-line with ports you would have the 'spirit of Arch' right there.

Primoz: Sometimes it is better that way.

some-guy94 · 2010-01-22 01:41:29

Primoz wrote:

You know what I realised? There's a lot of talk but minimum of action...
I know why I don't start developing it, because I don't know where to start. What do I try and compile kFreeBSD alongside Arch, do I install it in VirtualBox and then start from there, or something completely different?
Also I have no idea what exactly to do after that. I mean I know how to compile a kernel with help of yaourt and all but this is probably completely different.
With knowledge I'd install kFreeBSD and compilers, then wget sources for pacman etc.. and try to compile them...
But I don't actually know if this would work and all.

I actually am trying to build a cross compiler right now using the arch hurd scripts as a guide, but I seem to be missing some headers needed to build gcc.

They are in debian's kfreebsd-kernel-headers packge but I am still looking for the 'real' source of them.

Allan · 2010-01-22 01:42:39

some-guy94 wrote:

I actually am trying to build a cross compiler right now using the arch hurd scripts as a guide, but I seem to be missing some headers needed to build gcc.
They are in debian's kfreebsd-kernel-headers packge but I am still looking for the 'real' source of them.

That is a similar position to where I got "stuck" but I was not feeling persistent...

danielsoft · 2010-01-27 15:02:22

btw, "arch on FreeBSD" would need some interesting name:
what about "MallocBSD" ?

sand_man · 2010-01-27 23:00:48

danielsoft wrote:

btw, "arch on FreeBSD" would need some interesting name:
what about "MallocBSD" ?

I know what malloc() is but, I don't get it...

danielsoft · 2010-01-28 01:17:06

sand_man wrote:

danielsoft wrote:
btw, "arch on FreeBSD" would need some interesting name:
what about "MallocBSD" ?
I know what malloc() is but, I don't get it...

malloc() goes together with free(), so that's the point of the pun

sand_man · 2010-01-28 01:22:16

danielsoft wrote:

sand_man wrote:
danielsoft wrote:
btw, "arch on FreeBSD" would need some interesting name:
what about "MallocBSD" ?
I know what malloc() is but, I don't get it...
malloc() goes together with free(), so that's the point of the pun

Of course it does. Don't mind me

apollokk · 2010-01-28 19:48:14

Name it ArchBSD

(it would be show interesting to see this project being implemented!)

Primoz · 2010-01-28 20:25:07

apollokk wrote:

Name it ArchBSD
(it would be show interesting to see this project being implemented!)

I agree. As I'd preffer a Arch with kFreeBSD over BSD distribution with some of Arches ideas...

Arch Linux

#1 2010-01-17 17:18:23

Arch GNU/KFreeBSD: A more informed opinion.

#2 2010-01-17 17:54:44

Re: Arch GNU/KFreeBSD: A more informed opinion.

#3 2010-01-17 17:55:32

Re: Arch GNU/KFreeBSD: A more informed opinion.

#4 2010-01-17 18:53:40

Re: Arch GNU/KFreeBSD: A more informed opinion.

#5 2010-01-17 19:21:39

Re: Arch GNU/KFreeBSD: A more informed opinion.

#6 2010-01-17 19:46:40

Re: Arch GNU/KFreeBSD: A more informed opinion.

#7 2010-01-17 20:28:27

Re: Arch GNU/KFreeBSD: A more informed opinion.

#8 2010-01-17 21:58:30

Re: Arch GNU/KFreeBSD: A more informed opinion.

#9 2010-01-17 23:28:43

Re: Arch GNU/KFreeBSD: A more informed opinion.

#10 2010-01-18 01:38:22

Re: Arch GNU/KFreeBSD: A more informed opinion.

#11 2010-01-18 11:59:13

Re: Arch GNU/KFreeBSD: A more informed opinion.

#12 2010-01-20 18:49:25

Re: Arch GNU/KFreeBSD: A more informed opinion.

#13 2010-01-20 19:47:10

Re: Arch GNU/KFreeBSD: A more informed opinion.

#14 2010-01-20 22:49:55

Re: Arch GNU/KFreeBSD: A more informed opinion.

#15 2010-01-20 23:53:28

Re: Arch GNU/KFreeBSD: A more informed opinion.

#16 2010-01-21 16:39:17

Re: Arch GNU/KFreeBSD: A more informed opinion.

#17 2010-01-21 17:52:02

Re: Arch GNU/KFreeBSD: A more informed opinion.

#18 2010-01-22 01:41:29

Re: Arch GNU/KFreeBSD: A more informed opinion.

#19 2010-01-22 01:42:39

Re: Arch GNU/KFreeBSD: A more informed opinion.

#20 2010-01-27 15:02:22

Re: Arch GNU/KFreeBSD: A more informed opinion.

#21 2010-01-27 23:00:48

Re: Arch GNU/KFreeBSD: A more informed opinion.

#22 2010-01-28 01:17:06

Re: Arch GNU/KFreeBSD: A more informed opinion.

#23 2010-01-28 01:22:16

Re: Arch GNU/KFreeBSD: A more informed opinion.

#24 2010-01-28 19:48:14

Re: Arch GNU/KFreeBSD: A more informed opinion.

#25 2010-01-28 20:25:07

Re: Arch GNU/KFreeBSD: A more informed opinion.

Board footer