Slashdot Mirror

Bottom line for what you want, which is FreeBSD, start with the manual.

Then go to the releases and pick the latest production, i.e. stable, release (Currently 10.1). Everything will be stable and binaries and source packages for your desired functions will all be available and up to date.

if you want a dedicated machine for one specific purpose, then another BSD might be better, but for multiple purposes/general purpose, just use FreeBSD. It'll be just as good as the others for specific purposes (just not by default, you'll have to run a command to install software, big deal), many of which have a FreeBSD source.

Hi,
I've written a tutorial for installing freebsd on an encrypted root using a serial console. That should actually explain some things.

http://forums.smallnetbuilder....

Otherwise:

Get an installer image:
https://www.freebsd.org/where....

The release version is FreeBSD-10.1

try the memstick image
a "cp FreeBSD.img /dev/sdX" will copy it to stick

While you install:
don't install the package ports, you will get the freshest ones
through portsnap

Add an "admin" user make him member of group "wheel"
because that user can ssh and then "su" to root.

When you have installed FreeBSD

a.) run portsnap fetch extract
- after this your ports tree is up to date

b.) run freebsd-update fetch install
- after this your FreeBSD-system is up to date

c.) kill sendmail-demon
- after this you will feel no change at all

d.) installa samba via ports(verbosive) or via pkg add samba

you install things using the ports collection by enter the directory /usr/ports
where you choose the category for example the midnight commander can be found under "/usr/ports/misc/mc"

you start the installation using make install
afterwards you can do a make clean
or make distclean.

ports is "just" make-scripts

Hint:
svn is included in the FreeBSD base distribution
it can be called via svn-lite

So you can also checkout the current freebsd-head (FreeBSD handbook says how), browse the /usr/src directory or where yyou will then recognize that every command's source has a separate directory with make file etc..

Meaning you can now play with the source of the base distribution(userland) and kernel

FreeBSD is fun, and a base system really has a small footprint.

Because it can't be troubleshooted if all you have is something to read text files with. When all you have is a single user shell, for example. Or you've put the hard drive in a different system, which is whatever you had on hand and could even be Windows with an ext3 plugin.

Why would less work in single user mode but not journalctl? And nothing stops you or anyone else from writing a journal reader for Windows. The on-disk file format is not a secret.

Because it comes from the author of PulseAudio, who is world renowned for the stability of his products. And low CPU consumption, when they work.

PulseAudio runs on FreeBSD as well, just so you know.

Because it contradicts the Unix philosophy of having a lot of little utilities that each do one thing. It may not be a big deal for a full time sysadmin, but if your main job isn't that it's a lot easier to just read about the small parts that interest you and disable the rest.

systemctl disable $foo

And that's supposed to be easier just because $foo is implemented with a shell script instead of a .service file?

2. If he can write Linux kernel drivers, why does he need to ask Slashdot, or why doesn't he google it?
Because I don't know anything about BSD, and I'm not looking for "learn BSD in 10 easy mouse clicks". Although the signal to noise ratio on here sometimes approaches zero, there is the occasional informed opinion, and with a bit of luck, there will be some pointer to some actual pertinent information.

https://www.freebsd.org/doc/ha...
Recommended.

Personally I have no opinion about HTTP/2, but I have to say that this anonymous hit piece looks a lot like some IETF participant who didn't like how the process came out trying to create the appearance of consensus against it by pumping up the anger of the interwebs without actually saying what's wrong with the spec. When I see people making statements not supported by explanations as to why we might want to consider them correct, my tendency is to assume that it's hot air trying to bypass the consensus process.

It's also a bit annoying to see the IETF accused of having published a document advocating snooping when in fact someone floated that idea in the IETF and it was shot down in flames, and what we actually published was a document stating that snooping is to be considered an attack and addressed in all new IETF protocol specifications (RFC 7258).

What "anonymous hit piece"? Second link in the fine summary has a clear byline, Poul-Henning Kamp.

From the article:

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy.

I too would like more details, but I doubt he's just blowing smoke here.

FreeNAS's base is NanoBSD. http://www.freebsd.org/doc/en_... describes the project. The primary benefit of using NanoBSD is that everything is RO at runtime which means you can pull power from the system at anytime.

Another vendor who uses FreeBSD is Juniper. I've read about file system corruption--not often, but it can happen--from admins when they don't perform a proper shutdown.

I'll be holding on to this license as long as I can.

Which is what is currently happening to Linux, too. Escape Now ...bitches!

I think this fork will be fairly insignificant, and, further, that it will increasingly run into problems as desktops and other packages depend more and more on systemd components (that trend was one of the major factors in the Debian decision to adopt it).

Right! Lord knows open source software is known for its hard dependencies on system-specific interfaces, and for its contempt for cross-platform standards such as POSIX.

I mean, if you're on Windows, you're totally SOL if you want to use anything from Linux-land. Likewise, Mac users are totally f*ed if they want to make use of their OS's Unix roots to run Linux-oriented software.

Oh, and BSD users who want to run anything outside the system core? Out of luck. No one's going to bother taking all that Linux-specific code, which never pays attention to POSIX and uses syscall() into the Linux kernel everywhere, for such a fringe distro!

I guess we'll just stay in the world we are now, where everything on SourceForge is hooked directly into the Linux kernel, and the de-jure standards like POSIX and de-facto ones like GLIB are used as toilet paper for the Linux devs' asses.

Everyone knows almost all OSS software only runs on Linux right now anyway. Now it'll just be more of the same, but with SystemD dependencies built in, too! ...

Hmm, I think the LSD has worn off now. Ok, I have another opinion:

OSS software tends to follow portability best practices, where hard dependencies are eschewed when possible. A few corrupt, blinkered projects such as GNOME might decide to build in hard dependencies to SystemD. Most other software won't, because they'd lose portability to every platform other than Linux with SystemD. And most OSS software cares about that.

HAND.

I've done this myself as an experiment a few weeks ago. With the exception of FTB (the site has a jar file for it, so it'll likely work) everything you mentioned is available in ports. http://www.freshports.org/

There's also a binary packing system (pkg) but packages seem to randomly go missing there. A couple of weeks ago it was Xorg, until yesterday no Firefox. BTW can anyone explain the dynamics behind that?

The best way to get in is head first, install it on the least fancy PC you have. I'd strongly recommend FreeBSD and the handbook (This should be your first place of reference). http://www.freebsd.org/handboo... (take note of chapter 11). If you're a gentoo man you don't need PC-BSD.

Putting my view on *nix desktops aside (Are they worth the effort?), If there is a show stopper it'll probably be hardware support.

I use FreeBSD on all my desktop machines, and Gentoo on my laptop. Thankfully, eudev and USE="-systemd -consolekit -policykit" have kept my Gentoo install systemd-free. I tried FreeBSD 10.1 on my laptop, but poor battery life, suspend/resume issues, and X11 crashes forced me back to Gentoo.

The FreeBSD ports tree should have almost any FOSS project you're looking for. There was a period of time during the GCC->Clang transition where a lot of stuff didn't build, but those days are long gone. I'm not sure about Minecraft, but OpenJDK 7 and 8 work just fine. Mplayer is also in the ports tree, though I've long switched to mpv. VirtualBox, as well as Firefox and Chromium are also easily installed from ports. Flash can be made to work easily enough using FreeBSD's Linux compatibility layer. Not sure about OpenRA (I assume that's a game?), but you might have luck using the Linuxulator with that as well.

Encrypted root is possible using ZFS now. There's an option for it in the installer. Openbox, XFCE, Qt, are also all available from the ports tree. Honestly, I've never found a Linux program I used that wasn't in ports.

Coming from Gentoo, you'll feel right at home with FreeBSD. The system is much more easily configured, using a central, well documented config file (/etc/rc.conf). The handbook is great. In addition, compiling package from source is a much more user friendly experience than Gentoo. Compile-time options are presented to you via an ncurses menu the first time you install an application, and compile times are much faster with Clang compared to GCC.

I go to http://www.freebsd.org/release...
It says FreeBSD 10.1-RELEASE may be downloaded via ftp from the following site:
But that site resets connection immediately
It says However before trying this site, please check your regional mirror(s) first by going to:
Yeah well they don't have a regional mirror for the USA. I mean, that is it. I know because I tried.
So then I tried Canada's regional mirror, because it seemed logical. There is no FreeBSD directory on it. Guess that's not a FreeBSD mirror any more.
So then I see More information about FreeBSD mirror sites can be found at:
So I go there (https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html)
I try the second link and finally find the mirrors, and the ISOs.

Maybe someone ought to try following these directions before giving them. Obviously they can be followed with some trial and error, but it's pretty lame that I can't just get to the downloads with one click. Maybe two, allowing for a failure on the first attempt. The release document should give enough information to download the release without referring to another document.

Off to see if the actual experience is any better

FreeBSD 1.0 was released November 2 1993. The 21st anniversary was just a few days ago.

Suspend/resume has been broken there since 2008, and drivers for any recent Intel graphics adapter will not run (you cannot switch from Xorg to a console and back) properly.

[...] Your comment about not being able to switch between X and console suggests your knowledge is at least two years out of date. It was true for a short while in -CURRENT (the development branch) but never the case in a -RELEASE version.

Not true, 10-RELEASE has this issue. I'm experiencing it first-hand, but to also quote your handbook:

6.4.1. Caveats
[...]
Intel: as of FreeBSD 9.1, 3D acceleration on most Intel graphics, including IronLake, SandyBridge, and IvyBridge, is supported. Due to the current KMS implementation, it is not possible to switch between the graphical console and a virtual console using Crtl+Alt+F#.

Don't quote me one it, or maybe, yes you can. But BSD is real Unix, whereas Linux is posix compliant/compatible, but not a "real" unix.

Not that it really matters, it's all just semantics at this point, I think...

https://www.freebsd.org/doc/en...

until the Systemd fiasco blows over.

Not going to happen.

If only there were sane and well-designed OS the developers of which actually think about the consequences of what they're doing.
Oh, wait. there are.

For the record, Yahoo, running FreeBSD, was compromised via Shellshock.

When stating for the record, you should probably get it right. Yahoo's systems were _not_ compromised via the bash bug; they were compromised via some poorly written script that either was written in part as a shell script, or passed an unquoted header or query value to a subprocess, a la system(3) or popen(3). For the Record, FreeBSD does not use bash for /bin/sh.

Apple's Darwin kernel, which both OSX and iOS run on top of, was forked from the very same kernel Yahoo's servers run

Apple's Darwin kernel was not forked from FreeBSD. A quick web search could have told you that.

I'm not disagreeing with your point; only with the misinformation supplied as given in your validating arguments.

I've never done it, but if you're managing that many FreeBSD servers you can use poudriere to build packages from ports with your preferred options and then deploy them as binaries. That should give you the best of both worlds.

It's so close, can you feel it? https://www.freebsd.org/where....

Have they gotten USB 3.0 support working yet?

I think OSX uses SystemD, so it is INVULNERABLE!

Actually, it uses Apple's own creation, "launchd", which they Open Sourced.

Except, of course, that the Linux world can't/won't use it because it isn't under the almighty GPL, the "one license to rule them all".

So, they can't/won't use the APSL, because Apple, who wrote the software, allows it to be included in Proprietary software, which The GPL has Deemed to be Unclean.

However, I posit this: If the GPL controls the disposition of the Author's software beyond the point at which the Author herself even wishes, in exactly which way is that "Free"?

But now that launchd is Apache 2.0, what's the problem?

If you are asking for "real proof", that goes both ways.

So until there's proof, there's no valid reason to change current practice. Let sales and marketing provide proof, as opposed to hand-waving, that the current practice needs to be changed. The onus is on them, since they want the change.

This had been appreciated by our support and developer community, as they can readily see what issues are addressed and what new features have been introduced.

You don't need to make your internal bug tracking software public to do this. You only have to provide release notes. You can go one step further and publish a roadmap if you feel that is helpful. But none of this requires you to "air your dirty laundry". The fact he tries validate his decision with facts that don't actually back him up just shows me he doesn't have a very good argument.

I've emphasized the word "support", because the people doing the support are most likely the customer's in-house staff. If they're giving good feedback to their bosses, how is that a counter-argument? To the contrary, it does bolster his claims that it's good for business.

People know all software has bugs. Hasn't stopped Microsoft, Apple, IBM, Amazon, from doing business. If marketing doesn't know how to "feature" this openness - by emphasizing the responsiveness to users (not that it's open per se), then they're idiots.

If people are so knowledgeable about the fact all software has bugs, why do none of the huge companies you mention openly list their internal bug tracking data? They all have huge and experiences sales and marketing departments, and all of them feel it is not a good idea. Some cloud companies do publish very detailed uptime and maintenance reports, but that is because of how wary companies still are about trusting another company's uptime statistics. They still don't openly publish unfixed bugs

That one took only seconds to debunk. The number one smartphone software in the world in terms of sales has a public searchable bug list., including open bugs. FreeBSD, which is the base of OSX and which Apple contributes heavily to, lets anyone browse all bug reports or just open ones.

You're incorrect. The default shell is tcsh on FreeBSD, and bash isn't even installed by default.

I only have experience with ZFS, so I don't know if this is a general feature of RAIDs. I've run tests on my home zpool; the benchmarks show that read speeds on the pool increase from 20-200% as more disks (parity or data) are added (the new forum layout crops the plot; blue/red/yellow = RAIDZ1/2/3). I presume this is because IO operations can be partially parallelized across the pool. For me the biggest selling point is that my file server is only dependent on my disks; if any part of the server dies, I am not locked in to anything. For that matter I can even have 3 out of the 11 drives die, and my data are still intact and can be moved to other hardware if needed.

Why the hell is a GUI system dependent on a low level system control daemon?

Ever heard of policikit? consolekit? multiseat support? vt-less consoles? suspend/resume features? network management?

Since systemd provides all of this into one package, and no other system, as of today, provides multiseat support, and since consolekit last commit was 1.5 year ago, and the last tagged release for polkit was 1 year ago, it makes sense.

Also, finally we have a centralized way of handling suspension and resume features, instead of every desktop environment reimplementing the whole damn thing (that breaks every daemon trying to do the same, btw).

Frankly, I like systemd. It should be taken out of the hands of Lennard now, since I do not believe he is capable of handling such a project, but I like its features and what it means for linux.

No other init system or distribution was capable of utilizing the features of the linux kernel so deeply until now.

The good part about systemd is that it uses dbus for communications. DBUS is getting merged in the linux kernel *AND* in the freebsd kernel, so compatibility software like this can be used.

Lennard did not realize that he had to separate 2 things: the DBUS API and systemd itself -- Have I already said the I don't think he is able to manage such a system?

systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

Indeed. It shook me so hard, I fell off the Linux world.
Not looking back

...at all.

It was: http://www.freebsd.org/securit.... FreeBSD has OpenSSL in the base system, but can simultaneously have a different version installed via the ports system. Make sure you update both.

From man tunefs:
BUGS ....
          You can tune a file system, but you cannot tune a fish.

Fixed.

Me - adrian@freebsd.org. Also, https://wiki.freebsd.org/Netwo... .

Hi,

That'd be me (adrian@freebsd.org)

https://wiki.freebsd.org/Netwo...

Well, if OS X isn't working on your hardware, why not cut out the middle-men (Apple Inc.) and install the free and open source OS that they copied most of it from; FreeBSD http://www.freebsd.org/

People keep saying that Apple Inc. are innovative... I'm still waiting for them to innovate.

Not really - ports doesn't even have a *concept* of upgrading, it's just uninstall/reinstall and hope you can work out how to handle all the dependencies. This is why FreeBSD's got so many tools for managing them - portupgrade, portmanager, portmaster, all with their own little and not so little quirks.

We do have an apt-alike these days, in the form of pkgng. pkgsrc also has pkgin.

It is a "Tier 2" — so there are no official builds for it, for example.

It is a "Tier 1" for NetBSD, so you may have better luck there. They even distinguish between "ARM evaluation boards" (evbarm) and "StrongARM based Windows CE PDA machines" (hpcarm). I'm sure, OpenBSD is similar in this regard, but I'm tired of copy-pasting links...

ARM is a Tier 2 architecture for FreeBSD so I wouldn't get my hopes up too far, but you might get lucky.

http://www.freebsd.org/doc/en_...

No Linux variant has been certified according to the POSIX standards for UNIX, and most variants have subtle ways in which they diverge from the POSIX standards, at least subtly.

Haha. Now you've opened a completely different can of worms. For just one example: why should POSIX matter much these days?

BSD, for example, can essentially (though perhaps not completely technically) be called "Linux with extensions". (They deny it but their own description pretty much gives no technical differences except to say that Linux binaries won't run... and without further explanation that could simply be a compiler dead-man. The only specific difference they point out is licensing.) And the only real reason BSD isn't POSIX-compliant is because they have no interest in paying the fees.

Take OS X for example... it's built on BSD yet it IS POSIX-compliant. Because they wanted to be and paid the cert fees. Big deal.

If OS X and even Windows can be made POSIX compliant (they can), then just about anything could be made POSIX compliant if the owners wanted to bother. They just don't want to.

So now that the waters are thoroughly muddied, I'll muddy them further by saying: today, if you're not an Enterprise shop... you should ask yourself whether you really have any reason to give a shit.

FreeBSD just issued a security advisory w.r.t. OpenSSL. You better update to -STABLE asap.

Instead of Truecrypt, I'm considering using GELI on a wide scale. I'm wondering about its quality, cryptography-wise.

For music that I want to hear in its entirety, I use cdrdao to rip an entire audio disc to a single file. I use mplayer to play the file.

Here's the howto:
https://forums.freebsd.org/vie...

mplayer is available for Windows too.

The BSDs use the rc init system. FreeBSD uses the newer rc.d system. Slackware uses one of these systems as well.

Multi-Level Security was worked out in the late 1960s in order to allow computing both Secret and "Top Secret" information in the same computer at the same time. The use of the Bell-LaPadula model ensures that a lesser privileged user can never cause grief for a more privileged user. If we had Mutli-Level secure systems, we could safely run any program we want in a sandbox, and it could never, ever crawl back out of it.

The closest you're likely to approach is if you enable the MAC option in FreeBSD, which is experimental.

The Genode project aims to provide a capability based security system which can run Linux Apps... it is the best chance I see going forward for a truly secure system that isn't military grade. In such systems, you specify at run time exactly which files can be accessed by an application. This has the benefit of explicitly limiting the side effects of said application, and thus making for a far more secure system. You might be tempted to think this would make it unusable (as App-Armour tends to be)... but it doesn't have to be that way. In fact, it's possible to make apps behave almost identically, as far as the user is concerned, without compromising anything.

I think we're still 10 years out before people wake up and realize that our collective assumptions about computer security are wrong, and this needs a more rigorous, carefully engineered solution, instead of the layers of patch we currently employ. I'm hoping that my frequent postings on this subject are informative, and help shorten that timespan significantly.

Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?

* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)

* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html

* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/

* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)

* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.

There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.

Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.

My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac

Actually, it sounds like the docker people "invented" jail.

My guess is it's a takeoff on the classic sysctl.

Two key corrections:

1. It's UDP (the protocol) not UPD. Contextually I understood though, and assumed typo until I saw...

2. It's ntpd v4.2.7 not ntpd v2.4.7.

Also, the recommended solution is not just to limit noquery, but others as well. This comes straight from the FreeBSD stable/9 ntp.conf as of 2013/12/27:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0

Last 3 lines are effectively "allow". For what these all do, refer to the ntp.conf man page.

http://www.freebsd.org/

For routine operation of Internet-exposed systems, the / (which includes /usr and, usually, /usr/local) mounted read-only. The user-modifiable places (/home, /tmp, /var) are mounted with the noexec option.

Although a dedicated attacker might be able to succeed anyway (the same script can be run with a sh script instead of ./script), it throws sort of a "tangle-foot" over them — most of the hacks involve some compiled binaries. And, if the targeted filesystem is mounted read-only, even root can not modify it (remounting without a shutdown can be prohibited by policy).

What exactly are you trying to get at?

BSD-licensed software is doing great these days. FreeBSD 10.0 was just released a few days ago, offering some superb functionality that we don't even see offered by any Linux distributions yet. Part of that is their seamless integration of LLVM and Clang. In case you missed it, there was a story here on Slashdot earlier today about how LLVM/Clang are making Richard Stallman himself shit one brick after another. LLVM/Clang are starting to crush the living hell out of GCC.

NetBSD is still found in all sorts of networking gear and other embedded situations. And OpenBSD is going strong, too. It's more relevant than ever, giving the increasing importance of security these days. That's why they just raised $100,000 in direct user funding. And their OpenSSH offering is used on basically every Linux system these days, too.

Then there's OS X, which is a heavy user of BSD software. Their contributions to LLVM/Clang have helped push it mainstream. And their operating system long ago eclipsed Linux in terms of desktop usage share, and is now encroaching on that of Windows.

And then there are all sorts of projects on GitHub that are licensed under the BSD license, or the nearly-identical MIT license. It's rare to see a *GPL license being used for new projects there.

These are excellent times for BSD-licensed software projects. They're doing better than ever, and they're continually providing more and more value, and more and more freedom, to their users constantly.

Before anyone considers upgrading or installing FreeBSD 10.0-RELEASE, it is recommended you first read the Errata (particularly the Open Issues section):

http://www.freebsd.org/releases/10.0R/errata.html

Some of these might come as a shock to readers, especially the killall argv parsing bug and the ipfw fwd link-layer bug.

pkg IS the default package management utility

pkgng is the project which spawned pkg * replacing the previous pkg_* tools

http://www.freebsd.org/cgi/man.cgi?query=pkg&apropos=0&sektion=0&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html

So, do you have a timeline for when other *BSD and Linux distributions switched to signed packages? It looks to me that FreeBSD only started that move at the end of October, and doesn't appear to be there yet. I don't think I would call that a "crushing" lead.

There wouldn't happen to be some trolling going on with your post, is there? Especially the "security by arrogance" bit?

Thu Oct 31 02:10:33 UTC 2013

Pkg 1.2 will be released in the coming month which will bring many
improvements including officially signed packages. FreeBSD 10's pkg
bootstrap now also supports signed pkg(8) installation.
 

Google is funding this (both the direct research on FreeBSD and the port to the Linux kernel) because it addresses an aspect one level above the browser. Google Chrome would then be quite tightly sandboxed. This sure beats my method of running browsers as another user (I symlink ~/Downloads to my web user's version of that area and move things out of it quickly), especially since my method wouldn't do anything against actual privilege escalation (to root).

This should also help fight web server exploits (among other malware), especially w.r.t. installing rootkits. Should be great ammunition for advocating *Nix over Windows 8.

I'm excited, but I can wait for it to hit Linux (probably; FreeBSD will release with it by default in few weeks).

Won't the DDR take "50 to 150 cycles" to service each request? Or is there some sort of pipelining going on, where the DDR can take a request every 10 cycles but have a whole bunch of queued requests in flight?

Actually, that's pretty much exactly how it works. If you have a bunch of independent requests to DDR—and by independent, I mean that the processor(s) do not stall waiting for the information from one request in order to make the next—then you can get multiple requests in flight and they can pipeline. Streaming works this way, for example. The STREAM benchmark is a textbook example of a benchmark dominated by throughput, where all the accesses are independent. For example, a[i] = b[i] + c[i] does not depend on a[i - K] = b[i - K] + c[i - K] or a[i + K] = b[i + K] + c[i + K] for any value of K in STREAM's "Add" loop. All four loops of the benchmark have that character. So as long as the processor can get enough work in-flight, it can get multiple cache misses outstanding to DDR. And if one processor and its caches have limited ability to 'execute ahead' like this, multiple processors (or multiple independent threads on the same processor) acting independently can fill in those gaps.

Linked list traversal results in a series of requests that are all dependent on each other. If all the requests miss the caches and must go out to DDR, then the CPU's performance is bounded by the round trip latency to DDR, not the DDR's throughput. Take a look at the linked list benchmarks in Ulrich Drpper's paper, "What Every Programmer Should Know About Memory." (Specifically, go down to section 3.3.2 on page 20.) Pay particular attention to Figure 3.15, Sequential vs. Random Read (for a single thread), and also compare to Figure 3.21 which shows multi-threaded random accesses for 1, 2, and 4 threads.

The paper might be a little old (it uses a Pentium 4 for its benchmarks, after all), but the principles remain true. I should know... part of my day job is as a memory system architect. :-)