Slashdot Mirror

That's a terrible idea in a multi-user environment, because when the Apache process dies any other user can open that port (they may even open it accidentally) and now they get all of your web server traffic.

On modern UNIX systems; however, it is possible to grant the permission to open specific low ports. For example, on FreeBSD the portacl MAC framework policy can control this. On Linux SELinux can do the same thing.

"BSD", as some idiot quoted it, is NOT a "License", it's a *Copyright*. There is a huge difference there. Get it right.

The BSD style Copyright is now best represented by, and deployed as, the following...

https://www.openbsd.org/policy.html https://cvsweb.openbsd.org/src... https://www.freebsd.org/copyri...

With additional discussion here... http://landley.net/toybox/lice... https://urchin.earth.li/~twic/...

You should also know that the next major release of FreeBSD 12.0 will be out in 1.5 weeks :-) You can liveboot the RC3 sampler from USB today.

Copyright is a legal concept emblazoned in the United States Constitution and in many other countries around the world. To make a lot of legal stuff as simple as possible, it means "if you write the code, you own it and have the right to say what happens to it". Since you are the owner, you now have to do something to allow usage by someone else. That "something" is the license. BSD is a license, not a copyright. BSD always was more permissive than most other licenses, and over the years it removed the few requirements that it had, until now the "0BSD" license is almost indistinguishable from "Public Domain" software. However, it is best to put a license somewhere in your code stream, just to let the people who want to use your code that they can and under what circumstances.

*BSD uses Mozilla's root certificate bundle.

No, but it will be soon enough. Cancerous politics consume organizations from the inside out, distracting them from their original goals. Eventually, the organization will be consumed with identity politics, and software development will take a back seat to 'inclusivity' along with the other ideological shibboleths that typically accompany it.

Choosing developers out of some misguided attempt at 'equality' along irrelevant attributes will eventually cause those with talent to leave. If the conduct code forces humorless and stifled interactions between developers, those with talent will leave. If the conduct code encourages witchhunting and extreme 'conformation', those with talent will leave.

It'll boil down to the zealotry levels of those in charge, of course, but there's reason to be concerned when such draconian conduct codes are adopted. The fact it's based on the geek feminism wiki should be concerning to anyone who cares about freebsd.

https://www.freebsd.org/intern...
scroll to bottom

> Ransomware typically wipes any network drives using the SMB protocol, as Samba does, if the infected machine has access to the share :nods:
--Yep, but once you A) isolate the infected machines and B) ssh into the server and do a ZFS rollback (to a pre-infection snapshot time) on the ZFS-backed Samba dataset, all is back to normal again :D Rollback even "deletes" the infected files for you. ZFS snapshots are immutable unless you have basically root on the server.

https://forums.freebsd.org/thr...

https://github.com/zfsonlinux/...

FreeBSD doesn't have runlevels, which are a System V concept.

You're probably thinking of securelevels.

Except when it is in a closed source app, so such fixes cannot be put in until the company decides to do the fix

The same problem exists in open-source world too. Tons of packages bundle other packages inside. This is such a pervasive problem, FreeBSD, for example, has a special page instructing porters to fight it — and many still don't...

OpenOffice used to be the worst offender, bundling just about everything (python, libxml, boost, xmlsec — you name it). Firefox and Thunderbird continue to bundle their own jpeg, nspr and nss, vpx, vorbis and ogg, zlib and bz2, ICU an graphite2, harfbuz — something, a building system needs to patiently overwrite with --with-system-foo for every "foo".

There is nothing to lose from mixing open- and closed-source. The more of the former, the better. Moreover, the sole reason the latter even exists is to protect proprietary secrets from competitors. Including, as so often happens, the secret of how bad it is...

The closed source model relies on the fact that problems are harder to find

Yeah, this is known as the infamous "security through obscurity". It may be harder to find for a script-kiddie — who would not find it in an open-source package either — but not for dedicated professionals, who research exploits for a living and sell them to the highest-bidders.

You may think you have time to fix your code and ship an update, but you really don't. And, if you are a customer, you are completely at the vendor's mercy — without the source code, you can't fix it yourself.

So when your OS needs that extra push over the cliff FreeBSD goes to 11

The biggest issue I have with GNU is the lack of respect of the time and effort it goes into coding.

The biggest problem I've had with GNU/GPL software is two fold:

• Avoiding breakage at all costs.
• "I'm not getting paid to fix it, just use it as is" mentality.

On top of that it seems like a lot of tools were developed in a weekend by a single individual to scratch an itch and move on. GNUMake seems to be one of the biggest ones that everyone runs into. No one wants to make any changes that break stuff because then people will complain, and at this point so much needs to be 'fixed' that it'll never happen. And no one wakes up thinking "I'll take time to do this right" because they won't ever get paid for any improvements they make.

When I started doing FreeBSD development and working with BSD userspace it felt 'broken' at first, but after sitting down and RTFM, it feels like they actually put thought into some design decisions. And yes, sometimes stuff breaks. But they seem to give a fairly big heads up of any breaking changes.

And if something is up to date and maintained it appears that people are being paid to fix it and keep it working. I dig through BSD project commits and a lot of individuals at big companies making small tweaks to keep things running. The nature of the license doesn't scare away the lawyers and when I see a BSD binary that does everything I need it to I kind of tell myself "This is what I'm *allowed* to see, the cool stuff must still be behind closed doors".

How much cruft and dead weight is in GCC because of the myriad of platforms it needs to support and the way in which it supports them?

LLVM started off as a graduate project where it looks like someone actually sat down and thought about use cases. If I want to port a new language to a platform I just have to make a $LANG to intermediate representation (IR) parser.

The same thing goes for porting LLVM to a new architecture, I just need to make the IR to byte code part. I don't have to waste my time working out the C, C++, Fortran bits and can concentrate on supporting my architecture.

I'm sure that Apple, IBM and Google have some incredibly awesome tools they can't or wont show us. Probably some stuff highly specific to what ever they need to support. And if that's what puts food on their table, it works for me.

Anne Dickison set her LinkedIn to private in the past half hour or so, so I've done the world the service of mirroring it on PasteBin:

https://pastebin.com/4eDQ99xe

It's not surprising she's made it private, as it indicates not a single technical accomplishment over a 15+ year career. Indeed, you have to wonder how she is credited as "author" of the new code of conduct, when it's copied nearly verbatim from the Geek Feminisim Wiki. And since it's copied nearly verbatim, you also have to wonder what actual work Anne did during the entire year of 2017 -- a Q4 2016 report states she had been "overseeing the efforts to rewrite the Project's Code of Conduct to help make this a safe, inclusive, and welcoming community."

You have just violated the FreeBSD Code of Conduct for harassment. Specifically:

Physical contact and simulated physical contact (e.g., textual descriptions like "*hug*" or "*backrub*") without consent or after a request to stop.

And this is why I don't like vegans.

The latest FreeBSD Code of Conduct now has clauses to protect vegans. Which is total bullshit because vegans are like a cult that harasses everyone who isn't one of them.

You can catch more flies with honey than vinegar. Of course honey isn't vegan, which explains everything you need to know about vegans.

FreeBSD already has Linux binary compatibility, but that's helped a lot by the fact that the FreeBSD team has access to the source and can even re-use some of the code if they want.

So if you want similar functionality for MS Windows, a big step would be having a copy of the code to build it from, but not 100% necessary. There is a lot of API documentation out there, so as Microsoft forces programs to actually use documented features and not take shortcuts (currently in the name of security), it's likely to be more feasible to just drop in an executable and have it run.

It would be a good secret project for someone like Dell to try, in order to announce one day that they are switching all their computer sales and their new OS was windows compatible with software. It would only save them $25/computer and they may have some legal expenses as a result, so they may not see it as worthwhile.

Not trying to start a flame war even remotely, but nothing in your reply refutes the fact that the licensing is why these companies choose the BSDs. They don't pick BSD for superiority; Legal likes BSD license because it's compatible with IP, while GPL inherently isn't. I'll even add Netflix into the company list: they use FreeBSD on very specific back-end machines (and very few of them), but everything else is Linux (this comes from someone who actually works there).

FreeBSD was a good solid OS in the 4.x days, possibly lingering into the 9.x days. 10.x onward are pretty bad (you need to follow commits and mailing lists to understand these claims. They are not without merit). One of the worst problems introduced in 10.x is how load average is completely unreliable, which is still there as of 12.x/HEAD, despite the problem being 100% reproducible on both bare metal and VMs. DragonflyBSD is more promising in the sense that it's based on the development approach of 4.x and massively improved to work with present-day systems, hardware, and needs (Matt Dillon was one of the first people to track down the Ryzen bug); several FreeBSD committers (src and ports) switched many years ago for a multitude of reasons (some political). Instead in FreeBSD, people focus on mission-critical things like breaking ABI compatibility because the word rendezvous was spelled rendevous. There are only a couple kernel developers who remain that are of high quality: Konstantin Belousov and John Baldwin are two main ones; Warner Losh still lingers somewhere and comments on proposed the quality of proposed commits, and Alexander Motin does good work on storage subsystems and ZFS but his other stuff is questionable. Go through svn-src-all sometime and you'll see the names are few and far between compared to olden days.

Modern Linux (I am talking about the kernel/OS, not userland, and not a distribution!) is substantially better, and actually supported by device vendors for device drivers and kernel-level software. I name some names later.

GNOME and KDE and Wayland aren't relevant to any of the companies I listed and what products they make that use BSD, apparently with the exception of Citrix (I'm only familiar with their NetScaler devices, which were originally from the company of the same name (Citrix bought them in 2005)). These companies are using BSD kernel and partial userland (i.e. not ports/packages), plus their own in-house-developed binaries.

systemd isn't a requirement for Linux (though I fully agree it's a travesty and should be abolished, and am also terrified of how fast it was adopted across so many major distros), but there are distros which don't use it. I will admit that the downside to using one of these less-known distros is that their general support is worse; for example, Devuan, the Debian fork that lacks systemd, has questionable ZFS support (and its ZFS maintainer is some guy who sounds like he should be on a hacker's IRC channel). I would really love to know why so many distros switched, including some which were server-focused; OpenRC really seems like it's suitable for both servers and desktops. As someone who had to migrate EC2 servers running Ubuntu 14.04 LTS with in-house Upstart scripts to 16.04 LTS, I've really learned to hate systemd. Hours of my life and time absolutely wasted. But the kernel is still good.

ifconfig is userland, not kernel, but I agree it's "deprecation" (for the ip(8) command) is silly, but this is a per-distro thing (many distros still include it). In contrast, remember when ISC tri

Not trying to start a flame war even remotely, but nothing in your reply refutes the fact that the licensing is why these companies choose the BSDs. They don't pick BSD for superiority; Legal likes BSD license because it's compatible with IP, while GPL inherently isn't. I'll even add Netflix into the company list: they use FreeBSD on very specific back-end machines (and very few of them), but everything else is Linux (this comes from someone who actually works there).

FreeBSD was a good solid OS in the 4.x days, possibly lingering into the 9.x days. 10.x onward are pretty bad (you need to follow commits and mailing lists to understand these claims. They are not without merit). One of the worst problems introduced in 10.x is how load average is completely unreliable, which is still there as of 12.x/HEAD, despite the problem being 100% reproducible on both bare metal and VMs. DragonflyBSD is more promising in the sense that it's based on the development approach of 4.x and massively improved to work with present-day systems, hardware, and needs (Matt Dillon was one of the first people to track down the Ryzen bug); several FreeBSD committers (src and ports) switched many years ago for a multitude of reasons (some political). Instead in FreeBSD, people focus on mission-critical things like breaking ABI compatibility because the word rendezvous was spelled rendevous. There are only a couple kernel developers who remain that are of high quality: Konstantin Belousov and John Baldwin are two main ones; Warner Losh still lingers somewhere and comments on proposed the quality of proposed commits, and Alexander Motin does good work on storage subsystems and ZFS but his other stuff is questionable. Go through svn-src-all sometime and you'll see the names are few and far between compared to olden days.

Modern Linux (I am talking about the kernel/OS, not userland, and not a distribution!) is substantially better, and actually supported by device vendors for device drivers and kernel-level software. I name some names later.

GNOME and KDE and Wayland aren't relevant to any of the companies I listed and what products they make that use BSD, apparently with the exception of Citrix (I'm only familiar with their NetScaler devices, which were originally from the company of the same name (Citrix bought them in 2005)). These companies are using BSD kernel and partial userland (i.e. not ports/packages), plus their own in-house-developed binaries.

systemd isn't a requirement for Linux (though I fully agree it's a travesty and should be abolished, and am also terrified of how fast it was adopted across so many major distros), but there are distros which don't use it. I will admit that the downside to using one of these less-known distros is that their general support is worse; for example, Devuan, the Debian fork that lacks systemd, has questionable ZFS support (and its ZFS maintainer is some guy who sounds like he should be on a hacker's IRC channel). I would really love to know why so many distros switched, including some which were server-focused; OpenRC really seems like it's suitable for both servers and desktops. As someone who had to migrate EC2 servers running Ubuntu 14.04 LTS with in-house Upstart scripts to 16.04 LTS, I've really learned to hate systemd. Hours of my life and time absolutely wasted. But the kernel is still good.

ifconfig is userland, not kernel, but I agree it's "deprecation" (for the ip(8) command) is silly, but this is a per-distro thing (many distros still include it). In contrast, remember when ISC tri

FreeBSD has added IO throughput and IOPs caps per jail. https://www.freebsd.org/cgi/ma...

readbps filesystem reads, in bytes per second
writebps filesystem writes, in bytes per second
readiops filesystem reads, in operations per second
writeiops filesystem writes, in operations per second

BHYVE also supports via
limit_rbps Limit guest disk read throughput to the specified bits per second.
limit_wbps Limit guest disk write throughput to the specified bits per second.
limit_riops Limit guest disk read iops to the specified number of operations per second.
limit_wiops Limit guest disk write iops to the specified number of operations per second.

These limits can be done as a total per jail or VM or even specified per device.

https://wiki.freebsd.org/Docke...

A big ol ball? My init.d was about 13 scripts big which were readable and editable.

On what distro was this?

Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in /etc/fstab mounted. For example, is /var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is /usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.

Ever tried to edit systemd files?

Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.

Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.

Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.

You copy the existing file from /usr/lib/systemd/system to /etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.

Systemd makes every system into a dependency mess.

Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.

Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).

However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.

According to it's documentation, FreeBSD behaves the same way (thought the option name is different):

If the option ``failok'' is specified, the system will ignore any error
          which happens during the mount of that filesystem, which would otherwise
          cause the system to drop into single user mode. This option is imple-
          mented by the mount(8) command and will not be passed to the kernel.

They aren't "available to install if someone feels like being edgy", at least not without some manual effort of fetch'ing (that's the FreeBSD pseudo-equiv of wget), using strfile(8) (bet you've never heard of it until now, have you?), and dropping non-pkg-managed files into /usr/local/share/games/fortune manually. So, if by "being edgy" you mean "making a port/pkg for it", guess what: I've done exactly that:

* https://github.com/koitsu/fortune-mod-freebsd-classic (also contains history of what was done by FreeBSD Project members)
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223798

I refused to sit by and watch Ken Arnold's work (the import of classic 4.4BSD-Lite fortune into FreeBSD was done 23 years ago) and part of BSD/UNIX history get thrown in the trash. My hope is that this makes several people happy (probably us old UNIX beardos who still have a sense of humour and don't get triggered by seeing words they disagree with).

The committers responsible for the modifications and removals (especially the latter) should have done the above.

Here's the full diff.

https://svnweb.freebsd.org/bas...

I think it's not exactly sincere Hitler supporters that are the only ones that could think the change a bad idea. I would think pretending those things were never said because we are hurt they were ever said is harmful for the future. Lest we have public figures repeat many of those patterns without recognizing the problem because we bury our heads in the sand at the past when it offends us.

https://svnweb.freebsd.org/bas...

Already published: https://www.freebsd.org/securi...

...arrived October 16th at 22:44 UTC:

https://lists.freebsd.org/pipermail/freebsd-announce/2017-October/001805.html

Native apps work

Only on one operating system. Good luck (legally) running a native app distributed as a .dmg on anything but a Mac.

Nope. Windows runs Linux binaries. FreeBSD runs Linux binaries. Linux, BSD, and macOS run Windows binaries. Windows 10 on ARM runs x86 Win32 binaries.

Then what else runs macOS binaries? I thought this was clear from "distributed as a .dmg", as .dmg is the archive format commonly used to distribute macOS applications outside the Mac App Store.

So until a particular developer can scrape together the budget to produce multi-platform releases, is the solution to test in Windows and in Wine on either FreeBSD or GNU/Linux, distribute Windows binaries, and expect users of GNU/Linux, FreeBSD, and macOS to use Wine? If so, this strategy still misses mobile.

And that's not even mentioning of cross platform native applications. I use the same web browser and email client on all three operating systems I regularly use.

That's because the Chrome and Firefox web browsers and the Thunderbird mail client have enough of a budget for multi-platform development and testing. A hobbyist or startup may not have enough financial resources to launch simultaneously on all native platforms. "Just use Qt" isn't enough; a developer still has to buy the appropriate hardware (namely a Mac with enough RAM to run the other operating systems in VMs) and spend labor on testing on all supported operating systems.

Native apps are also OS-specific. Only on one operating system.

Nope. Windows runs Linux binaries. FreeBSD runs Linux binaries. Linux, BSD, and macOS run Windows binaries. Windows 10 on ARM runs x86 Win32 binaries.

And that's not even mentioning of cross platform native applications. I use the same web browser and email client on all three operating systems I regularly use.

How are native applications only on one operating system again?

https://www.freebsd.org/

Personally, I don't give a crap whether people adopt or contribute to the OS. It's there for their use if they want, if not they can use something else.

If you want to make crucial business decisions out of ignorance that's your prerogative.

You seem to be implying that FreeBSD is going to immediately port all their 3rd party software to any new GCC that gets released in the future during the support period, but that is not actually how FreeBSD versions work

I didn't mention GCC. The default compiler for anything that hasn't actively been marked as requiring GCC is clang. The ports framework has flags to indicate required features of a compiler. If a port is marked as needing C++14, then it will be compiled with either the system compiler (if it supports one), or one from ports if required. The infrastructure for doing this is used automatically by the package-building infrastructure, so a port that needs a newer compiler than the one shipped in the base system will automatically get the one from ports.

The actual reality is that FreeBSD will get most new versions later than even Centos!

An assertion without evidence. We run a few CentOS machines at work and getting anything that needs a newer C++ version than was available when the base OS shipped is a huge amount of pain. Let's look at available packages for CentOS 7 and FreeBSD 10 (both released 2014 and still supported). What's the latest clang version available for them? Actually, that doesn't seem to be a fair comparison, because CentOS doesn't seem to include clang packages (and LLVM is only packaged for MESA) but, for reference, FreeBSD 10 has packages for clang 3.8 to to the 5.0 release branch (5.0 isn't yet out, but there are packages for the latest snapshot from the release branch). Okay, let's make a more fair comparison: how about gcc, since that's the system compiler for CentOS? Well, the CentOS package list has a compat package for GCC 4.4 for compiling older stuff, and an up-to-date package for GCC 4.8.5 (released June 2015), which predates most C++14 features. So, as I said, compiling C++14 code on CentOS is a pain. Okay, let's look at FreeBSD. GCC isn't the system compiler and you've said it lags updates and is behind CentOS, so I guess it will be older? I see packages for GCC 4.6, 4.7, 4.8, 4.9, 5.4 (after 5.0, GCC changed its release numbering, so 5.x is a release series, previously 4.9.x was a release series), 6.4, 7.11, and the (unreleased) 8 release branch.

And no, they don't just slavishly follow the upstream release schedule, they actually couldn't do what you imply if they wanted to because so much of their 3rd party software gets local changes to make it more secure, which then isolates them from upstream and means new versions have to be basically back-ported. So you don't even get all the released versions.

Again, look in the ports collection (follow the svnweb link next to any port to see the history of files that have changed). Most ports have no patches, or trivial ones to change a couple of paths in the build system, and these typically don't change much between upstream versions other than being removed if they're upstreamed.

Stable is only useful if it's both stable and usable. The system ABIs across a stable FreeBSD release series are guaranteed to be compatible, but that doesn't mean that you can't run newer software and there's little use in a system with long-term support if support just means 'we won't change anything' - that's not support, that's atrophy.

Linux has gotten a lot simpler through the years.

Hahahahahahaha. Oh wait, you're serious? Let me laugh even harder.

Honestly, Linux has become a giant clusterfuck over the last years. In comparison, FreeBSD is all about maintaining the POLA.

It does not include systemd nor PulseAudio

If you're going to use your release notes to bash a certain individual, at least make sure you get rid of the other skeletons in the closet.

I've been thinking about trying FreeBSD (currently run Mint 18.2) How well does it perform on semi-modern hardware?

Historically, the FreeBSD kernel is bomb-proof, fast, and efficient. I wouldn't worry so much about that. It will be pretty efficient, especially if you build your own kernel eventually.

But, also historically (and I'm not current with the latest version), FreeBSD might not have the support for as many devices as Linux, as Linux probably has more contributors. Here's the hardware support

The userland should be huge, as the ports collection has a huge amount of code which has been ported to FreeBSD.

Fire it up in a VM and play with it. I think it also uses a slightly different filesystem layout, but again, I've not installed it in some time.

Chances are if you have pretty mainstream hardware, it will work just fine.

Going on 4 years now, originally introduced in 10.0-RELEASE: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 (read the comments don't skim them, else start at the bottom and work upwards)

Possibly you meant moved *by* the application?

Are you just being obtuse? It seems perfectly clear that buchner.johannes was referring to the elimination of a copy-to-userland copy-back-to-the-kernel roundtrip.

As you say, that's just what happens.

Awesome! How can we turn off ALL data collection? Show us THAT link and we are golden...

Here it is.

And a bonus one!

Why can't we turn it off entirely?

But you can!

As a linux user and an anti-fan of systemd, I thought I'd give FreeBSD a try - it's been years since I last gave any BSD a go. I was going to put it in a VM, but poking around I found there's now versions for ARM SBCs like the RaspberryPi. According to the wiki the RPi2 is best supported. Cool! I've got one of those I've been meaning to eBay, and a 2GB uSD card from the 35mm film canister of too-small-for-raspbian-or-the-crud-on-my-phone microSD cards.
So I dd the image on, plug the Pi into a network cable and an HDMI monitor and boot. Yep, nmap says it's dhcp'd to ...125 SSH-Log in as freebsd/freebsd (had to look that up) and su (root/root - ditto) Great! Now, what can I do? Load moar stuff! port? Nope. pkg!

root@rpi2:/home/freebsd # pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended

Ok, what does that mean? This is a new install! Ah well!

root@rpi2:/home/freebsd # pkg-static install -f pkg
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be REINSTALLED:
                pkg-1.9.4_1
Number of packages to be reinstalled: 1
Proceed with this action? [y/N]: y

Done! Now where was I, ah yea, installing stuff.

root@rpi2:/home/freebsd # pkg search vim
pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended

That didn't fix it - what does it mean? Google! Nope, everyone else with this message really upgraded, not from a fresh install.

So, first thing I try and do gives an unGoogle-able error message. That's enough playing about, I'll try a BSD again in a few more years.

As a linux user and an anti-fan of systemd, I thought I'd give FreeBSD a try - it's been years since I last gave any BSD a go. I was going to put it in a VM, but poking around I found there's now versions for ARM SBCs like the RaspberryPi. According to the wiki the RPi2 is best supported. Cool! I've got one of those I've been meaning to eBay, and a 2GB uSD card from the 35mm film canister of too-small-for-raspbian-or-the-crud-on-my-phone microSD cards.
So I dd the image on, plug the Pi into a network cable and an HDMI monitor and boot. Yep, nmap says it's dhcp'd to ...125 SSH-Log in as freebsd/freebsd (had to look that up) and su (root/root - ditto) Great! Now, what can I do? Load moar stuff! port? Nope. pkg!

root@rpi2:/home/freebsd # pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended

Ok, what does that mean? This is a new install! Ah well!

root@rpi2:/home/freebsd # pkg-static install -f pkg
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be REINSTALLED:
                pkg-1.9.4_1
Number of packages to be reinstalled: 1
Proceed with this action? [y/N]: y

Done! Now where was I, ah yea, installing stuff.

root@rpi2:/home/freebsd # pkg search vim
pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended

That didn't fix it - what does it mean? Google! Nope, everyone else with this message really upgraded, not from a fresh install.

So, first thing I try and do gives an unGoogle-able error message. That's enough playing about, I'll try a BSD again in a few more years.

This renders your joke irrelevant, but NetBSD can run some Linux binaries.

Read about it here: https://wiki.netbsd.org/guide/linux/

The NetBSD port for i386, amd64, mac68k, macppc, and many others can execute a great number of native Linux programs, using the Linux emulation layer. Generally, when you think about emulation you imagine something slow and inefficient because, often, emulations must reproduce hardware instructions and even architectures (usually from old machines) in software. In the case of the Linux emulation, this is radically different: it is only a thin software layer, mostly for system calls which are already very similar between the two systems. The application code itself is processed at the full speed of your CPU, so you don't get a degraded performance with the Linux emulation and the feeling is exactly the same as for native NetBSD applications.

FreeBSD has similar functionality.

This is one of the reasons why so many former Linux users have moved to FreeBSD or NetBSD after being driven away from Linux by systemd, PulseAudio, GNOME 3, and other problematic software like that. Most Linux programs worth using compile just fine on the *BSDs, but if there are legacy, closed-source Linux applications that must be used there is at least some chance that they may work on FreeBSD or NetBSD. This makes for a very easy transition path away from Linux, or more correctly, away from systemd (it isn't the Linux kernel itself that most people have problems with, of course).

Yes, try FreeBSD, the OS which no longer reports correct load average due to what appear to be "changes for the sake of change", with no one taking responsibility (c#7 onward). This applies to 10.x and newer.

systemd sucks hard, but it is not a reason to consider FreeBSD. A better approach is to either find a distro that still uses SysV init or some equivalent (ex. OpenRC), or grudgingly bite the bullet and try to disable (through config files) the annoyances of systemd (ex. restore text logging vs. binary logs).

Of course you still can. Just download it directly from the FreeBSD site. The point I was making is that the lawsuit delayed general adoption of FreeBSD just enough to allow linux to get some traction.

cx88 PCI cards

http://corona.homeunix.net/cx8...

https://gist.github.com/dreamc...

xc5000 USB device)

https://wiki.freebsd.org/Webca...

Requires dvb-fe-xc5000-1.6.114.fw firmware

https://www.linuxtv.org/downlo...

MythTV

http://www.freshports.org/mult...

Primary reason *I'm* moving away from FreeBSD (been using it since 1997): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 -- issue has existed since 10.x (last version I verified was 12.x). 9.x is now officially EoL'd.

I've also begun to witness strange intermittent performance problems with ZFS and mutt: extremely slow paging through mails (the mailbox is a classic UNIX mail spool/mbox, not Maildir); the ARC is 100% primed with said contents, and the issue simply goes away randomly but will reappear at some point in the near-to-late future. A full zpool scrub passes, absolutely no anomalies with the system otherwise; all server-class hardware. It's one of those things that is infuriating because there's no real explanation for why it's happening that one can immediately discern from sysctls.

As for Linux distros that don't use systemd, http://without-systemd.org/wiki/index.php/Main_Page is a common go-to, but I imagine that list will slowly over time have fewer and fewer entries (ex: CentOS). Sad situation, really.

Your addons = that vs. my work & can they build a hosts file for you?

The addons mentioned modify the hosts file... Yes, an addon is capable of building a hosts file.

They also have usermode slowness/messagepass overhead & can't protect the browser from a BAD addon trying to redirect you (hosts can).

Again, addons can modify the hosts file too, making this point irrelevant if you want to talk about addons being able to touch hosts files.

Do addons run in DOS (or FreeBSD)?

Yes.

* Might as well kill your other post too: DNS is LOADED with security & efficiency issues

And yet, I have identified numerous areas where hosts files are in comparison, highly inefficient and wasteful.

Agent Smith (Kowalski), there is no way around it, you have lost. No amount of dossiers will save you now.

Blind hope that your choice of operating system is safe is the worst form of security. From the article:

When you deliberately choose and operating system so inconvenient by default that it's not even part of the mainstream conversation, it's hardly blind hope.

USB Tethering: How to auto-configure?

I have an LG G2 phone that can share its mobile internet via USB tethering. FreeBSD 9.3 recognizes it, but does not automatically obtain an IP address via DHCP and set it to the default route when I enable USB tethering on my device. Is there any way to do that? Just like under Windows.

I'm guessing, on the basis of that final sentence, he hadn't been bumping along on the BSD anti-bandwagon for very long.

Convenience, the simple recipe:
* mise en place: read everything Bruce Tognazzini ever wrote, back in the era where Apple still provided some modicum of external justification for random UI tweak of the randomly selected mountain
* blend into one long, hard night of inspired coding
* activate brew with one generous Pandora's box jigger of "assume trust"
* ladle up hot, attractive mess
* serve steaming

Nope a mistake. They meant to say 802.11n support added for additional WiFi drivers in their errata.

This reminds me of Kernel 2.6.0 mentioning supporting SMP mistakenly by the media.

Boy the mcses at work were laughing and mention Server 2003 rules and had that for years! Grrr

There are plenty of security-focused Linux OSes, e.g. Tails, Qubes, Whonix, Ubuntu Privacy Remix, Kali Linux - just to mention a few. And then there is also the whole BSD family of free Unix OSes who are very security vetted, e.g. NetBSD, OpenBSD and FreeBSD. So I'm not sure what you mean by "the linux community is not capitalizing on the situation" ..?

So now PC-B, er, TrueOS is tracking FreeBSD-CURRENT? What exactly is their intended use-case? From the wonderful FreeBSD manual:

FreeBSD-CURRENT is the “bleeding edge” of FreeBSD development and FreeBSD-CURRENT users are expected to have a high degree of technical skill. Less technical users who wish to track a development branch should track FreeBSD-STABLE instead.

FreeBSD-CURRENT is made available for three primary interest groups:
1. Members of the FreeBSD community who are actively working on some part of the source tree.
2. Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches.
3. Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution.

FreeBSD-CURRENT should not be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way “officially supported”.

I thought PC-BSD was a nice, easily-set-up systemd-free desktop OS with ZFS. I've used it on older systems and it was pretty nice. No way would I use it for anything important if it's going to be tracking Current, though, and have to deal with the headache of extra bugs and instability. Even FreeBSD doesn't recommend it unless you're a tester or contributor.

Am I missing something? What are the benefits of this move? Will the TrueOS team be able to provide support for the inevitable bugs that come up and annoy users?

Is Debugging turned on for FreeBSD betas?

Interestingly, the style Mr. Torvalds prefers has been part of BSD's style(9)
manual for decades.

I'm a bit irked when people say 'BSD' to refer to FreeBSD only... I thought that was a 2002 thing but people still do it, it seems.

No such manual page exists on Open or NetBSD.