Earlier quoted context omitted.
It may just have been once packages were installed. I started using Unix ten-ish years ago with RedHat, and even as a beginner I saw that using RPMs quickly became a mess of inconsistent paths and circular dependencies. It was sloppy. Not even "bleeding-edge testing release" sloppy, just sloppy. The situation has probably improved, but I moved on to Debian, then OpenBSD. I'm still happy with OpenBSD, but my next choi…
> It may just have been once packages were installed. The whole OS is packages. The first thing that goes on a new system during the OS installer (anaconda, again more than 10 years old) is the glibc package. 10 years ago I assure you no package of the thousands included in Red Hat Linux put something in /usr/local.
Ask HN: I'm a Linux guy. Tell me about all those BSDs
101–110 of 167 posts
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#102I used FreeBSD and OpenBSD for a while, and what drove me back to GNU/Linux was package management. OpenBSD was OK at it even if it had a limited selection, but I never had much luck with FreeBSD ports. Having a nice, stable base system wasn't very useful when ports were always being updated to the latest version; if I wanted a security fix, I had to take all the feature changes and new bugs, too. I tried a bunch of…
Binary package management in FreeBSD isn't well-advertised, but it's definitely there: # portupgrade -rvP --batch foo-1.2.3 This will upgrade installed package foo and anything that depends on it using binary packages from the mirror site, falling back on a build from source. Installing a new binary package: # portupgrade -vNP bar/baz If you're using portaudit to stay on top of vulnerabilities (it's part of the defau…
For example, take a Firefox or PHP security vulnerability. Those projects generally don't just release a new version with the security fixes; they'll throw in whatever feature changes they've made along the way. I don't want to sort through the various changes and patches to find the right combination; trust me, it's no fun, I worked on the Debian security team for a while. It's important to me to get just the security fixes because I don't have time for a constant upgrade treadmill and there will be new bugs in with the new features.
I really want my operating system to just work and get out of the way. If I didn't need any packages from ports, I think FreeBSD would fit that bill.
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#103Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#104I've been using OpenBSD for several years (since 3.4...wow, that's almost seven years), as my primary OS. I had been running Debian for 2~3 years, and Red Hat (briefly, ick) before that. A lot has been covered already, but: 1. The BSDs feel significantly more cohesive to me. Other people have mentioned this, but it deserves greater emphasis. The config files, man pages, etc. are quite a bit more consistent, and my fi…
For dynamic Web-based applications, what advantages do OpenBSD have over Linux?
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#105Earlier quoted context omitted.
>The GCC compiler and toolchain aren't optimal, and I fully expect a major Linux distribution to switch to Clang/LLVM in the not too distant future. Have you looked through the Linux kernel code? There is a lot of gcc specific stuff in there. I don't think the Clang change will be as fast as you think.
The worst that can happen is porting GCC features over to a GPL-licensed Clang fork.
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#106I have been an OpenBSD and FreeBSD user, as well as minor contributor, since the mid-90s. All the answers here are good, and I would like to add: * FreeBSD is on the cutting edge of performance. Because it is a total OS (as opposed to just a kernel), performance improvements are made and integrated into the binary packages and ports build options of common packages. FreeBSD was one of the first operating systems to i…
Each time i've tried a "stable" release right out the gate (5.0, 6.0, 7.0) I have had numerous random crashes and bugs in the default install. I always have to wait a few minor revisions for the bugs to be worked out. Of course, i'm a Linux guy, so maybe i'm doing something wrong.
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#107Earlier quoted context omitted.
Not really. The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris. That's clearly undesirable. Sun faces a lot of competition from IBM and HP, both with offers to migrate to AIX/HP-UX and to Linux on x86 hardware. Enhancing Linux was a big no-no for them.
> The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris. Yes > That's clearly undesirable Why? Sun's been bleeding customers towards Red Hat and (to a far greater extent) Novell since the early 2000s. Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) kill…
Giving Dell all the tools to fight SPARC/Solaris effectively would only kill it faster.
As a high-end hardware manufacturer, they were pressed from below by Linux on cheap x86 hardware. One possible solution would be to press back with SPARC/Solaris hardware at x86 prices. Sticking to the high-end may be a good strategy, but that's why IBM does not make an x86 version of zOS.
And that's why they lawyer to shreds anyone who tries to sell and support zOS on emulated zSeries hardware.
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#108Earlier quoted context omitted.
> It may just have been once packages were installed. The whole OS is packages. The first thing that goes on a new system during the OS installer (anaconda, again more than 10 years old) is the glibc package. 10 years ago I assure you no package of the thousands included in Red Hat Linux put something in /usr/local.
Well, ok, it may have just put them in /etc, /usr/opt, /etc/local, and /moustache. It wasn't that it did or didn't put things in /usr/local, but that there wasn't a consistently followed layout like OpenBSD's ( http://www.openbsd.org/cgi-bin/man.cgi?query=hier ). Also, like I said - it's probably gotten better since ten years ago. It was really annoying, though, and I'm not misremembering things: I specifically switc…
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#109Earlier quoted context omitted.
> The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris. Yes > That's clearly undesirable Why? Sun's been bleeding customers towards Red Hat and (to a far greater extent) Novell since the early 2000s. Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) kill…
> Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) killed the company. Giving Dell all the tools to fight SPARC/Solaris effectively would only kill it faster. As a high-end hardware manufacturer, they were pressed from below by Linux on cheap x86 hardware. One possible solution would be to press back with SPARC/Solaris h…
Re: Ask HN: I'm a Linux guy. Tell me about all those BSDs
#110Earlier quoted context omitted.
> It may just have been once packages were installed. The whole OS is packages. The first thing that goes on a new system during the OS installer (anaconda, again more than 10 years old) is the glibc package. 10 years ago I assure you no package of the thousands included in Red Hat Linux put something in /usr/local.
Well, ok, it may have just put them in /etc, /usr/opt, /etc/local, and /moustache. It wasn't that it did or didn't put things in /usr/local, but that there wasn't a consistently followed layout like OpenBSD's ( http://www.openbsd.org/cgi-bin/man.cgi?query=hier ). Also, like I said - it's probably gotten better since ten years ago. It was really annoying, though, and I'm not misremembering things: I specifically switc…
* Config files go in /etc.
* Spools, caches an so on go in /var
* Binaries for all users go in /bin if they're important, /usr/bin if they're less so
* Binaries for root go in /sbin if they're important, /usr/sbin if they're less so
The standard was mature a decade ago and long before then. I suspect you just may have not been used to the standard.