pkg repository for FreeBSD 10

Here is how to use it:
  1. Create /usr/local/etc/pkg.conf with this content:
    Code:
    packagesite: [url]http://pkg.cdn.pcbsd.org/10-STABLE/amd64[/url]
    PUBKEY: /usr/local/etc/pkg-pubkey.cert
    PKG_CACHEDIR: /usr/local/tmp
  2. Download pkg-pubkey.cert to /usr/local/etc.
  3. Upgrade your packages with pkg upgrade -fy.
 
Do you really work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.
 
vanessa said:
Do you really work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.

I have an AthlonXP 2000+ still running FreeBSD. It is 32bit, and is my home NAS, as well as a backup desktop for when my Phenom2 crashes.
 
In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.
 
vanessa said:
Do you really work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.

I do because the only equipment I have that is totally silent and is otherwise suitable for my application (firewall) happens to be a VIA C7 based mini-itx motherboard that is not AMD64 compatible. The i386 architecture is not going anywhere soon.

All my other machines are 64-bit capable though but they are too noisy and use too much power to keep running 24/7.
 
vanessa said:
Do you really work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.

Most are multi-core, but I believe the 5S is the first 64-bit mobile device. Samsung is on board with going 64-bit, so should be seeing some next year.
 
break19 said:
In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.

Not exactly. PC-BSD stopped with 32 bit because they're using ZFS by default. And ZFS on 32 bit simply has too many issues. That's why they dropped support for 32 bit. Also keep in mind that PC-BSD is a separate project.
 
Beastie said:
Really really.
Ah okay, I'll keep a note to dump my perfectly-fine 32-bit machines in the trash first thing in the morning... Not!

No offence, I thought I am the only one with some 32-bit machines lying around. But I definitely don't use them for FreeBSD, because, as @break19 said, it takes forever to compile something.
 
Last edited by a moderator:
One misconception about 64 bit seems to linger. It's not faster than 32 bit! Both 32 bit and 64 instructions are processed in exactly the same amount of time on the processor. Only certain floating point operations are faster because they're implemented differently. Building world or the kernel doesn't use floating point operations so building on the same machine using 32 bit or 64 bit takes the same amount of time.
 
kpa said:
I do because the only equipment I have that is totally silent and is otherwise suitable for my application (firewall) happens to be a VIA C7 based mini-itx motherboard that is not AMD64 compatible. The i386 architecture is not going anywhere soon.

All my other machines are 64-bit capable though but they are too noisy and use too much power to keep running 24/7.

Yes, the VIA C7 is a fine one. However I don't think that 32-bit automatically means less noise and power. This is because the C7 is a processor, optimised for power efficiency. I am sure that the new A7 ARM in the iPhone 5S is even more power efficient (despite being 64-bit) and being on par with or faster than the C7.
 
SirDice said:
One misconception about 64 bit seems to linger. It's not faster than 32 bit! Both 32 bit and 64 instructions are processed in exactly the same amount of time on the processor. Only certain floating point operations are faster because they're implemented differently. Building world or the kernel doesn't use floating point operations so building on the same machine using 32 bit or 64 bit takes the same amount of time.

Yes, this is true. The speed loss comes from the age :)
 
break19 said:
In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.
Spot on!

SirDice said:
Not exactly. PC-BSD stopped with 32 bit because they're using ZFS by default. And ZFS on 32 bit simply has too many issues. That's why they dropped support for 32 bit. Also keep in mind that PC-BSD is a separate project.
You're exactly right about why the PC-BSD project dropped the i386 architecture, that is ZFS optimally requiring 4 GB of memory and KDE (the default DE) requiring at least 512 MB to run decently.

But I believe you misunderstood what @break19 meant: i386 machines (being much older than most modern amd64 ones) have barely enough memory and processing power to build some of the huge applications such as X.Org, Firefox, Chromium, GIMP, Open-/LibreOffice, etc. or essential dependencies such as Perl, Python, GTK, etc.

vanessa said:
No offence, I thought I am the only one with some 32-bit machines lying around.
None taken at all. My post was entire humorous; maybe I should've added more smilies (at the risk of angering our dear mods).
 
Last edited by a moderator:
Beastie said:
But I believe you misunderstood what @break19 meant: i386 machines (being much older than most modern amd64 ones) have barely enough memory and processing power to build some of the huge applications such as X.Org, Firefox, Chromium, GIMP, Open-/LibreOffice, etc. or essential dependencies such as Perl, Python, GTK, etc.
I have to disagree. I've been building those since the 3.x era and most of the time it was on i386. Yes, it will take some time. Building XFree86 on FreeBSD 3.x took almost a day. Things have very much improved since.

If you have multiple machines I'd suggest doing the building on a fast machine, build your own packages and transfer those to the 'slow' machines. You can quite easily build i386 packages on an AMD64 machine.
 
Last edited by a moderator:
tzoi516 said:
Most are multi-core, but I believe the 5S is the first 64-bit mobile device. Samsung is on board with going 64-bit, so should be seeing some next year.

True, but the 5S is already here - unfortunately not in my pocket :(
The new iPad Air has got the same chip too.
 
My experience in building binaries from ports has been that the speed limit is more dependent on HDD throughput rather than CPU speed. I'm isolating the "number of cores" factor from my statement, because obviously the number of poudriere build environments is directly dependent on number of CPU cores. But speed per core is not the issue.

If one does not have an amd64 (with multiple cores) based compiler unit and an i386 poudriere build jail, the next best thing to do would be to dramatically improve the HDD throughput speed on the i386 system.

This can be done by purchasing a PCI card providing SATA-III port outlets and an appropriate SATA-III HDD which will be plugged into the PCI card. The compile speed improvement should be quite noticeable.
 
Personally I lose hours and days by fixing ports not willing to compile, dropping options or drawing dependencies maps. HDD throughput or 32 vs. 64 bit don't even come to count in such a situation.
 
pkg.freebsd.org is now live. You can't browse that address directly, it's just a bunch of SRV records that point to the actual mirrors that host the actual files. But you can get the list of mirrors like so:

Code:
$ host -t srv _http._tcp.pkg.freebsd.org
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg0.bme.freebsd.org.
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg0.isc.freebsd.org.
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg1.nyi.freebsd.org.

And you can then browse the individual mirrors to see what packages are available for which release on which architecture. Just use the pkg.freebsd.org address in your pkg.conf to auto-select the best mirror.
 
However it doesn't seem to work :(
Code:
$ host -t srv _http._tcp.pkg.freebsd.org
_http._tcp.pkg.freebsd.org has no SRV record
 
Works here. You might be behind some weird proxy that breaks DNS look ups of SRV records or the DNS forwarder you're using strips them for some reason. Worth checking.
 
A simple fix might be just changing your router to use the Google DNS forwarders 8.8.8.8 and 8.8.4.4 instead of those provided by your ISP.
 
Back
Top