It's always intriguing to me how critical the BSDs and BSD programmers are to the Linux ecosystem, even though their user base is fairly small.
For dedicated server systems that developers don't access, it's pretty much perfect. I kind of wish that the developer world had standardized on that rather than GNU/Linux, though perhaps if there was a wider pool of developers, the BSDs wouldn't be so clean and straightforward.
That's exactly how I feel about it. You never want too many cooks in the kitchen. They have all they need for a very successful server system already.
Right now I'm just hoping for some sort of BSD-based desktop environment∗. Doesn't have to be a Windows/OSX/GNOME/KDE killer, just something functional. I suspect the usage of Linux GUI environments is going to become increasingly volatile in the future with so much Linux-only tech being pushed in as dependencies to absolutely everything these days.
(∗ I don't mean something like Lumina, I mean from the display server up. Xorg is moving to Wayland/Weston, GTK3 is pretty much becoming GNOME-only, which is becoming systemd only. I'd like to see a new BSD-style lightweight, modular, minimal display server, widget toolkit, and desktop. Run the whole thing on either VESA or barebones EGL.)
For example I can run GNU bash on an HPUX system.
My personal NetBSD experience has been that (on a laptop) my ATI Radeon was supported (back in the day) and currently, we've been experiencing "near misses" with accelerated gfx w/ Intel integrated (ie: i915) GPUs. NetBSD -current (7.99.1) is currently (on my Lenovo Thinkpad t420) unstably supporting accelerated graphics. I'm hoping this effort stabilizes and sticks around.
There is no nvidia binary driver, and no nouveau port. You only have the ancient nv driver, which is just a frame buffer. And an absolutely horrible one at that. It is at least 20x slower than pure VESA. I don't know how that's possible, but it's too ridiculous to make up. If I drag a window across the screen, it takes about five seconds for the system to catch up on the redraws.
OpenBSD also lacks the memcontrol utility, so you can't tweak MTRR (write-combine caching) for VESA (which increased my video bandwidth rate from 200MiB/s to 1,200MiB/s), unless you write your own C program to use the kernel API for doing that.
Even then, the real problem is that finding a video card that has your native widescreen VESA resolution is like winning the lottery. I managed to find a 2560x1600 card for my primary system, but I've yet to ever find a card that has a 1920x1080 VESA mode for my secondary PC.
The OpenBSD project refuses to include binary "blobs," and Nvidia just simply don't provide open-source drivers for their cards. There's been some indication recently they may be changing their stance on that, so we can hope.
All that said, the BSDs, and OpenBSD in particular do not have ultimate video performance as a goal. While OpenBSD is certainly usable as a desktop or laptop OS (I use it) you are best to stick with Intel or AMD graphics adapters. FreeBSD might arguably be a "better" desktop OS but I prefer OpenBSD's focus on consistency, security, stability, and documentation.
Sure, in the case of the nvidia binary-blob driver, that's very fair. It's the same net effect to the end user, though. nvidia+OpenBSD is an instant failure.
You can also blame nouveau relying on Linux KMS functionality, but I would like to see OpenBSD try a bit harder to run nouveau, given how ridiculously poor nv is. Really, nv is actually worse than nothing. I'd sooner run in VGA 640x480x16-color mode. It's that bad.
> All that said, the BSDs, and OpenBSD in particular do not have ultimate video performance as a goal.
I don't want ultimate performance to run Crysis (whatever # they are up to now) or Star Citizen or whatever is popular amongst gamers today.
I want a frame buffer that will let me drag a window across the screen without deadlocking my system for 5-10 seconds. I appreciate their pain with these damned video card manufacturers, but I don't think my request is unreasonable, either.
> you are best to stick with Intel or AMD graphics adapters
AMD drivers are absolute shit on every other OS, so I don't expect them to be reliable under OpenBSD. And unfortunately, Intel won't sell PCIe cards. I really, really, really wish they would.
But to me, the focus should not be on trying to run the latest games. Linux isn't replacing Windows for gaming, so there's no chance FreeBSD is going to.
I'm running a 2560x1600 display on VESA, and after a few MTRR tweaks, it's more than fast enough (I can push over 100 full frames per second), even for watching video and playing 2D games. The only thing missing is Vsync support in the protocol. And what I get in return is never seeing another graphics driver crashing my entire system (because we're still stuck with monolithic kernels running video card drivers in ring 0 in 2014.)
I would say, get a nice desktop up using only a frame buffer with maximum bandwidth possible. Then if people want to run an EGL context, they can render 3D stuff to a buffer, and blit that into a window, or do a fullscreen EGL app that controls the display. But that should be entirely optional and only used where needed. The BSDs are server OSes, so I think this is acceptable to favor stability over performance.
The best part would be that this could run on (top of, if necessary) any system. Windows, OS X, DOS, Haiku, Minix, you name it. If you could write pixels to a screen, you could run the display server.
How does that work? For long I've lamented the fact that VESA/VBE caps at some not-particularly-high 4:3 resolution. Also, the lack of DMA & vsync...
Having a simple way to drive modern displays at a reasonable speed would be nice. The complexity of the accelerated graphics stack is depressing... and I don't really want or need it. Hell, I didn't need it ten or twenty years ago, so why now.
The official VESA modes are all 4:3 (and 5:4 for 1280x1024). But most video cards have non-standard modes. These modes are usually just more 4:3 variants or really low-res 16:9 (1366x768, gee thanks!)
By some miracle, my PNY GTX 760 OC 2GB card had a 2560x1600x16bpp custom mode. No 32bpp mode, but in this case I'll take half the bandwidth requirements (twice the speed) for the extra color anyway.
The way this works behind the scenes is that the VESA VBE is part of the VBIOS image. This BIOS contains 16-bit instructions that poke the video card into video modes based on a table. Nowadays, 64-bit OSes just emulate the VBIOS instructions to set the video mode. Yet unfortunately none of them are proactive enough to let you specify your own modified VBIOS file to use in substitute (like you can with EDID)
Some people have had luck hacking the VBIOS and adding in their monitor modes, and flashing it back to the card. However, gaining that write access can be difficult, and often times these files are now compressed and/or encrypted.
> Having a simple way to drive modern displays at a reasonable speed would be nice.
God yes. I am so sick of the ridiculous complexity of everything these days. I miss the ease of working with serial, PS2, gamepad ports, SB16 cards, and VESA. Nowadays you need a team of 40 engineers to support the 10 USB variants (UHCI, EHCI, OHCI, XHCI, etc) just to poll a damned keyboard.
This stuff really cripples the chances for any hobbyists to ever come up with a new, breakaway, successful OS. I doubt Linux would ever take off if it had to start in today's SecureBoot / long-mode / SATA / RAID / USB3 / Wifi / binary-blob-graphics world.
A simple frame buffer with page flipping or Vsync really is enough to do pretty much anything 2D-based you'd want to. And at the rate CPUs are gaining cores, I suspect we could even pull of some really rudimentary software 3D rendering, too (not MESA, that tries too hard to emulate and is ungodly slow.)
Indeed we can; we could long ago. I think of that when I play games like Doom and Quake (which is often). They look awesome, they were software rendered. And to think that the effort on software renderers was more or less abandoned around when Unreal came out in 1998 -- that was pretty much the last FPS engine to have an advanced software mode (which looked amazing), and it worked for me back then since I didn't have a 3D accelerator. Where would we be at if that effort had continued for the next 16 years?
You can run Xorg on top of Wayland simply by changing the driver Xorg use.
Now if GTK or Qt drops their X support completely, that becomes a different story. But that don't seem to be a issue any time soon.
I am not an expert here, and I would be happy to be wrong. But I'd rather be proactive in planning for an eventuality where Linux software becomes just too difficult to port to the BSDs anymore.
While this is mildly off-topic, I'm mildly frustrated that there doesn't seem to be any BSD equivalent to hosts like Digital Ocean and Linode. The closest I've been able to find in recent searches is RootBSD, and its specs are... well, pretty sad for a VPS in 2014. Are there technical reasons that make this difficult to do with FreeBSD? I know you can't use a Linux-specific VM solution like KVM, but is there no BSD equivalent, or no VPS provider with a more OS-agnostic solution?
FreeBSD is available as an EC2 AMI.
For what it's worth, Nearly Free Speech[2] offers jailed hosting on FreeBSD and has recently improved their ability to handle persistent processes.
[1]: https://wiki.freebsd.org/bhyve [2]: https://www.nearlyfreespeech.net
You can also vote on this suggestion on the DigitalOcean website: https://digitalocean.uservoice.com/forums/136585-digitalocea...
I've had a lot of luck getting bleeding edge Arch linux kernels running on DigitalOcean using kexec to essentially turn the kernel DO gives you into a bootloader. It should theoretically be possible to get FreeBSD running in a similar manner, but it would obviously not be officially supported.
If you're looking for other hosting providers, EC2 does have FreeBSD images available.
It's actually possible to boot grub4dos via kexec, however it doesn't work out of the box in digital ocean. I'm not sure how to format code on HN so here's a proof-of-concept on pastebin: http://pastebin.com/5jcvG2N9
A kexec bootloader also exists, called petitboot, but I've never used it to boot anything other than linux, though scanning google, it looks like people may have used it to successfully boot FreeBSD on the PS3 or OpenWRT compatible routers. Petitboot can be found here: https://www.kernel.org/pub/linux/kernel/people/geoff/petitbo...
[1] Fall of 2001.
[2] Yes, Verio had those weird virtuals running on e10ks, but JC was the first to offer the VPS as we all came to know it.
Their features and prices are very competitive with Digital Ocean, which is a nice change for an Australian ISP.
[1] http://www.binarylane.com.au [2] https://www.binarylane.com.au/support/solutions/articles/100...
A few providers have started doing this, but more need to do this as it would cut down on the wasted ipv4 addresses that they have in "stock".
They're affordable and answer support tickets within minutes.
Vultr.com[0] offers FreeBSD VPS from $5/month. I've used these guys, and have been very happy with the offering.
Atlantic.net[1] offers FreeBSD VPS from $0.99/month.
TransIP[2] offers FreeBSD VPS from €5/month.
[0] https://www.vultr.com [1] https://www.atlantic.net [2] https://www.transip.eu
Edit: "critical to". My mistake.
Why? Do you think popularity reflects quality?
It is immediately evident to me that the popular BSDs (or at least FreeBSD and OpenBSD) are of vastly superior quality (both in terms of design and code) to Linux. I understand why people use Linux instead (it's generally for the same reasons corporate environments use Windows: legacy, large userbase, and familiarity), but it is definitely the case that by all my metrics, the BSD programmers have every right to be critical.
Like I said, sorry if I misunderstood your post.
--OpenSSL, not SSH.