"Linuxification" of FreeBSD -- am I the only one it bothers?

Because a(n evidently-un-QA'd) port stepped on my 10.3R system, I decided to up to 11.1. But I ended up reinstalling 10.3 because, like Linux, v11 no longer supports MBR partitions, making dual-boot with XP, which I still use, impossible.
My mistake -- my bios was set to allow either EFI or legacy, but the installer didn't know how to recover when it went down the EFI path and found an MBR record.

Then I went to reinstall the Nvidia video driver, and discovered that even the 10.3 port would install what looks like half of Centos. So I installed an older driver from my stash, instead.

This trend bothers me quite a bit; I'm sure it won't end well for us.
 
For the Nvidia video driver package, that's because it is built with Linux Binary Compatibility enabled by default.
That's why I prefer to build my own packages with options of my choice (No Linux enabled in this case). So I haven't any Linux Binary Compatibility Layer installed on my PC.
 
Because a(n evidently-un-QA'd) port stepped on my 10.3R system, I decided to up to 11.1. But I ended up reinstalling 10.3 because, like Linux, v11 no longer supports MBR partitions, making dual-boot with XP, which I still use, impossible. ...

For sure something went wrong on your side. The following output of gpart show shows the partition map of a running dual boot FreeBSD RELEASE-11.1p1 + Windows 10-1607 disk:
Code:
=>       63  312581745  ada0  MBR  (149G)
         63  156364767     1  ntfs  (75G)
  156364830       2018        - free -  (1.0M)
  156366848     919552     2  !39  (449M)
  157286400         30        - free -  (15K)
  157286430  155295378     3  freebsd  [active]  (74G)

=>        0  155295378  ada0s3  BSD  (74G)
          0  146800640       1  freebsd-ufs  (70G)
  146800640    8494738       2  freebsd-swap  (4.0G)
The point with PLAIN dual booting of Windows is, that you need to partition the disk with Windows, and the Windows partition shall be the first one. This is not a limitation of FreeBSD but of Windows, and it is not new with FreeBSD 11, but this has always been the issue. With PLAIN, I mean without any boot manager and/or otherwise sophisticatedly tricking the system to work.

Anyway, we are still able to create MBR partitions on FreeBSD, the following shows the partition map of my Beaglebone Black running FreeBSD 12-CURRENT:
Code:
=>      63  31116225  mmcsd0  MBR  (15G)
        63      8129          - free -  (4.0M)
      8192      8192       1  fat32  [active]  (4.0M)
     16384  31096832       2  freebsd  (15G)
  31113216      3072          - free -  (1.5M)

=>     63  7552961  mmcsd1  MBR  (3.6G)
       63     8129          - free -  (4.0M)
     8192     8192       1  fat32  [active]  (4.0M)
    16384  7536640       2  freebsd  (3.6G)
For me, FreeBSD 11.1 is a big one. IPsec is completely enabled in the kernel, including NAT-T, and USB3 errors which I experienced on 10.3 have been fixed. And booting is 25 % faster compared to 10.3.
 
This trend bothers me quite a bit; I'm sure it won't end well for us.

MBR boot method still works in FreeBSD and MBR become to "Legacy" regardless to Linux.
As for more and more Linuxisms - are you ready to rewrite all Linux software to FreeBSD ? ;-)
I think, after a while all our FreeBSD will have only linux-\* packages installed on the host, or will only work as a bootloader for bhyve with Linux inside.
Unfortunately, the last case takes place to be in my infrastructure for the last 5 years.
 
My mistake on 11.1 not supporting MBR!

The bios on this mamaboard has 3 settings: EFI only, legacy only, both. I had it set to both, and evidently the installer, defaulting to EFI, didn't know how to back up and try again when it found an existing MBR partition. [sigh]
 
For the Nvidia video driver package, that's because it is built with Linux Binary Compatibility enabled by default.
That's why I prefer to build my own packages with options of my choice (No Linux enabled in this case). So I haven't any Linux Binary Compatibility Layer installed on my PC.

I really don't want to go that same route because I've so much development work to do that they'll have to cremate my body to stop me working after I'm dead. And I've never done release engineering or spent more than 2 weeks in the role of sysmgr. But it looks like rolling my own will be my best choice. too. What toolset do you use for it?
 
I really don't want to go that same route because I've so much development work to do that they'll have to cremate my body to stop me working after I'm dead. And I've never done release engineering or spent more than 2 weeks in the role of sysmgr. But it looks like rolling my own will be my best choice. too. What toolset do you use for it?
Take a look at ports-mgmt/poudriere, it is great. I am using it to build locally my packages for my computers.
 
But it looks like rolling my own will be my best choice. too. What toolset do you use for it?
What makes you think you need one? See ports(7). Although having a tool to make building ports a little easier can definitely help never underestimate what you can do with the default tools.

If you take a look around /usr/ports/ports-mgmt, you'll find many different utilities there which can help you sort things out. I think it's fair to say that the most commonly used tools are Portmaster, Poudiere and/or Synth.

But like I said, sometimes a mere # make config-recursive install clean can also do the trick.
 
Back
Top