Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BSD vs. Linux (2005)

over-yonder.net

Post reply on HN
Print view View original

281–290 of 371 posts

Re: BSD vs. Linux (2005)

#281

Post by talideon »

throwaway7767 wrote: post #271
talideon wrote: post #200

Earlier quoted context omitted.

> the "FreeBSD Desktop" is even more so. The funny thing is that there's a reason for that: up until recently, the focus of FreeBSD has been on being a server OS. There's a push recently on improving the graphics situation, but it's only relatively recent, and is mainly focussed on getting integrated graphics on more modern hardware working. There are also some efforts to expand the driver compatibility layer so that…

IIRC FreeBSD was making some decent progress on the workstation experience before Apple released OSX. Once that happened, a lot of the people working on that switched over and the efforts kind of died down for a while. I haven't used FreeBSD on a desktop for years, but I've been told it's getting a lot better recently.

All very true. Part of the reason why the effort flagged was that suddenly there were these high-quality machines with a BSD userland around. Un/fortunately (depending on your perspective), Apple haven't put a tonne of effort into keeping that side of things as up to date as they might, so improving the desktop experience on FreeBSD again.

Up until 7.0 came out, the desktop experience was pretty decent, and things like audio and video (anecdote ahead) worked out of the box better than Linux. After that, things started to slip in comparison.

The work put into PC-BSD has helped with the out-of-the-box experience, assuming your have the right hardware, but it's good to see more effort being put into improving the general driver situation. I certainly wouldn't be at all against ditching Ubuntu and switching back to FreeBSD as my desktop OS.

Re: BSD vs. Linux (2005)

#282

Post by aseipp »

PeCaN wrote: post #44
smegel wrote: post #8

BSD has a wonderful, unified events system. That incorporates blocking disk IO. Linux has epoll. https://www.nginx.com/blog/why-netflix-chose-nginx-as-the-he...

BSD and Solaris (which also has kqueue, and something else IIRC) got this really right while Linux got this really wrong. I still prefer NT's IOCP, but kqueue isn't bad. epoll… is what happens when you get someone who's never done asynchronous I/O to design a system for doing asynchronous I/O.

Solaris has its own form of completion ports too, I believe. https://web.archive.org/web/20110719052845/http://developers...

NT's IOCP is good, sensible model overall having used it some recently. It's mildly put off by some "gotchas" (like async calls occasionally returning synchronously if there's nothing else on the queue, so you have to be careful with send, recv, etc), but the actual design is good. Thread pools being a convenient, native API in Vista+ is also a bonus.

Re: BSD vs. Linux (2005)

#284

Post by jiltedfrog »

idk much but this i will have to say based on what i have noticed windows is like an ultra modern machine gun with users who have no idea of what they can do with their machines while on the other hand and this is not entirely true, linux is like a old rusty single shot vintage gun, sure it wont work all the time but the guy running it has way more control and way more dangerous than the average windows user.

Re: BSD vs. Linux (2005)

#285

Post by eropple »

lisivka wrote: post #153
throwaway2048 wrote: post #122

Earlier quoted context omitted.

I'm sure that's of great value to him.

For me, it looks like a lie, because of no information about hardware, distro, kernel, etc. For example, pulseaudio works fine for me for at least 6 years on 6 notebooks and 2 workstations of various vendors (HP, Dell, Acer, Medion). But if it will work badly under heavy load, then obvious command will fix that: `sudo renice -n -10 $(pgrep pulseaudio)` .

Assuming that other people are lying because they have trouble with things you like is paranoiac behavior. The almighty Linux desktop is not important enough to lie about.

Re: BSD vs. Linux (2005)

#286

Post by Decade »

belorn wrote: post #160
merijnv wrote: post #127

Earlier quoted context omitted.

> Based on this thread, I'd say the problem is a lot of people haven't given them the time. > If you select your hardware, they work pretty flawlessly. Maybe the fact that I have to give them time is one of the major problems? You know how much time I invested in getting my Windows and OSX desktops to work flawlessly? Zero.

I do a windows reinstallation about once every second year, and I routinely get problems. Network drivers are almost always missing. Looking at the device manager, about 5-10 different devices fails to auto-install, all part of the motherboards. The default graphic drivers tend to "start", but is limited in refresh rate and resolution, and moving around windows shows a noticeable stutter until I install some official…

> I do a windows reinstallation about once every second year, and I routinely get problems. Network drivers are almost always missing. Looking at the device manager, about 5-10 different devices fails to auto-install, all part of the motherboards.

What are you reinstalling, Windows XP every time?

Newer versions of Windows are getting better at finding and installing sane drivers for the hardware. It’s still not perfect, Windows Update doesn’t have all the latest drivers and OEMs ruin everything especially on laptops, but these days I install the latest Windows and everything usually just works.

Re: BSD vs. Linux (2005)

#287

Post by aseipp »

sebcat wrote: post #185
cm3 wrote: post #155

Earlier quoted context omitted.

FreeBSD also has Netmap and DTrace out of the box. They will also get TLS support in sendfile(2) as soon as the patches from Netflix land in HEAD.

I understand the rationale for this (performance), but it scares me a bit to have something as complex as a TLS stack running in kernel-space, which I assume it will do.

The sendfile/TLS work from Netflix does _not_ rely on the TLS stack running in kernel space. TLS session management, negotiation, and data framing is dealt with at the application layer, via nginx/openssl. Once the TLS handshake is completed and session keys are derived, you bind your session key to a socket. The FreeBSD kernel then sees this, and when you call `sendfile` to push static data out of the socket through the page cache, it does "bulk encryption" at that point (presumably using nothing more than an AEAD or whatever TLS negotiated for you, with the given key). Basically, instead of read()/encrypt()/write() going through userspace, `sendfile` can just directly do something like `encrypt(static_data_in_page_cache_to_send, out_socket_addr)` when you call it, right there in kernel space.

The need for these cryptographic primitives isn't too onerous on its own, either; FreeBSD already needs them for IPSec (among other things probably), so the vast majority of needed, kernel-level encryption code was already there before this.

> ... which I assume it will do

I hate to lament or anything, but: ... why assume at all - they've written about it? I really wish people would just read the paper about this feature, because this is a large misconception about their work that nobody ever seems to get right, and I say this as someone who doesn't use FreeBSD at all, I just found the paper interesting. Everyone hears "sendfile with TLS support" and immediately jumps without actually reading.

Again, sorry to lament. It's just a personal nitpick or something I guess; the paper is very approachable though, so I encourage you to read it before assuming. I encourage you to do this with most papers - even if you don't understand it, since you might still learn something :)

A google search for "freebsd tls sendfile" brought me this immediately:

https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

The main points about this are on page 2, last paragraph on the right column, and page 4, paragraph after the bullet points on the left column.

That said, you always have to look at the code to determine if it's really something worth going upstream, for all the usual reasons.

Re: BSD vs. Linux (2005)

#288

Post by digi_owl »

ChuckMcM wrote: post #75

I like FreeBSD, and I use it as a server OS and on a NAS box but you only need look at https://wiki.freebsd.org/Graphics to understand that if the "Linux Desktop" is a joke compared to MacOS and Windows then the "FreeBSD Desktop" is even more so. From my experience of "old" computers, workstations, and then "PCs as Workstations", Windows won the desktop because the UNIX camp could never check their egos at the door a…

The base problem there is drivers. Specifically that we have something like 3 suppliers of desktop GPUs.

One refuse outright to supply information that allows a proper open driver to be developed.

Another have just started providing this information in recent years, and there is still delays between the latest hardware hitting the market and the proper information reaching relevant hands.

The third only recently started producing hardware, and said hardware is only bundled with other products from same supplier. Never mind that it in general performs worse than the other two offerings.

There used to be another, one that was supposedly well supported by open drivers. But that one long since left the consumer market, focusing instead on multi-display business setups etc.

so effectively you are complaining about how a group of people, forced to reverse engineer and often working in their spare time, can't match the market gorilla that gets direct support from third party suppliers.

Re: BSD vs. Linux (2005)

#289

Post by throwanem »

eropple wrote: post #119
aaron-lebo wrote: post #116

Earlier quoted context omitted.

That is bizarre. I don't use a lot of Ubuntu. Having had an issue with Ubuntu and nvidia in the past, you might want to google NOMODESET and setting it at boot, which should let you boot into X/Unity and get the latest drivers. > But I don't know many people for whom the operating system is more important than what you can do with it, and part of "what you can do with it" is "use your hardware." Absolutely. But if OS…

> Having had an issue with Ubuntu and nvidia in the past, you might want to google NOMODESET and setting it at boot. Thanks; I later ran into something that hinted at that. Frankly, though, at this point I don't care. I have something that works and will be patched until 2019. I don't care about my desktops. Every second I spend debugging something stupid on a desktop is a wasted second. This is bad for me and I rese…

> OpenRaster

Another ocean boiled, courtesy of the Free Desktop Project.

Re: BSD vs. Linux (2005)

#290

Post by lisivka »

eropple wrote: post #285
lisivka wrote: post #153

Earlier quoted context omitted.

For me, it looks like a lie, because of no information about hardware, distro, kernel, etc. For example, pulseaudio works fine for me for at least 6 years on 6 notebooks and 2 workstations of various vendors (HP, Dell, Acer, Medion). But if it will work badly under heavy load, then obvious command will fix that: `sudo renice -n -10 $(pgrep pulseaudio)` .

Assuming that other people are lying because they have trouble with things you like is paranoiac behavior. The almighty Linux desktop is not important enough to lie about.

I am leader of Linux User Group in my country, so I am aware about typical problems with Linux desktop. Last problem with PulseAudion on major distro, I heard off, was years ago.
Post reply on HN