Flame bait: Why BSD is dying, or How I learned to stop worrying and love Linux

Status
Not open for further replies.
SirDice said:
I think a lot of the issues Auld_Besom has can be solved if the ports tree would also have a -RELEASE instead of only HEAD. If I remember correctly there was some talk about this some time ago. People that want to can still track the current HEAD, while others can take a -RELEASE and only get security updates. I'm not sure what happened to that discussion but I can imagine it's been shelved for lack of resources.

I think that Auld_Besom has actually raised some good points. Indeed, OS is experienced by enduser as whole.

Point is, FreeBSD is currently offering huge repository of ports (after Debian, but Debian has overchopped many applications, so it's inflated artificially) and there is no, nor there will ever be enough manpower to offer scrutiny comparable to base system.

After all, it's alien to port system idea too. Think of it, it's a collections of simple scripts trying to be minimal and using just vanilla sources. It will always be a hobbyist/wizard thing. It is what it is (I personally like it, mainly for using vanilla sources and most of the time additions kept up to minimum.)...

But it will never be industry grade-binary repo similar to RHEL, there is just not enough manpower.

To be fair, there is "something" as port release. There was feature freeze in ports leading up to 9.1, which was lifted now. So one could use packages distributed only with 9.1, treating them as "released". However, reality is, port system is more akin of -STABLE or -CURRENT thing. That's price for fresh software.

If it would depend on me, I would delegate _more_ of the base to ports (yes, e.g. BIND), leaving just _base_ things, to focus on them, moreover this is good idea to me http://wiki.freebsd.org/FreeBSD-ng-detail , and would totally leave release engineering of binary-industrial-grade packages to interested (possibly financially, why not) third party!

adamk, well I like that you can actually run FreeBSD on newer intels. Most of linux numerical success now stems from this, that linux was hobbyist system at home for future sysadmin, and he just doesn't know any better. Not supporting any newer cards will not help it.

Sorry, but I think I must add this also. I don't remember last time I had problem with ports. I just don't install lots of crap... Port system eases you into installing lots of software, but shouldn't fool you into thinking they do not inherently (by design) suck (DE in broad sense for me).

tl;dr?

FreeBSD should just focus on providing slim excellent base, true to the original spirit of UNIX, not necessarily try to be released _product_ for all-and-every-possible-scenario enduser.
 
zspider said:
It's called PC-BSD, FreeBSD will never be suitable for the masses and that's just fine with me.

That's probably the case, and it is moving in the right direction, but it's not there yet.

Also, it's not just the desktop - server wise there's a long way to go also.

Setting a home server up as a NAT + firewall box with SMTP and a few other basic services should be no more than putting in some IPs, hostnames and ticking a few boxes with sane defaults. This stuff isn't rocket science, unless you're doing something really weird and out there, in which case you should know how to do it yourself manually. But the vast majority of people aren't, they're doing basic things. And even if i know what I'm doing, doing basic thing shouldn't require significant effort :)


Instead of having some sensible defaults like that, which work well enough for the 99%, FreeBSD (and Unix in general, it's not a problem exclusive to FreeBSD - don't get me wrong, I'm not having a whinge because I want to pick on FreeBSD, it's my unix of choice on servers) will offer say, 3 different firewall engines, no default out of the box firewall rule set and certainly no template to get it up and running. I mean, there are standard things you leave open on a firewall and standard things you generally block (e.g., inside IPs on your outside interface, etc). There's no safe template. People who want to do unsafe things because they know better should, well.... know better to be able to modify it themselves. Instead of forcing everybody to start from scratch...

Instead of having a home box doing basic stuff up and running within a couple of hours of first being exposed to FreeBSD (assuming basic network knowledge) the user is forced to learn a bunch of os specific peculiarities before they get very far at all.

Sure, a half competent admin will figure it out. But there are heaps of people out there who aren't competent admins, and end up configuring open relays, un-firewalled machines, etc.

I guess I'm just saying that it shouldn't be this hard.

I don't expect anyone to think "oh, well we'll start coding this right away", because I know resources are tight. And no i'm not likely to code it myself because personally I don't need the convenience stuff, and I don't have time. But I do see things like that as being detrimental to FreeBSD and Unix in general being a viable OS for a heap of people.

:)
 
Speaking of PC-BSD, well I could setup perfectly usable FreeBSD machine for a family member (and did it once), yet the time when he installed PC-BSD on it, and _then_ it started developing problems I was helpless over the phone. I would prefer to just wipe this altogether and start with fresh FreeBSD. So nothing is without consequences. He had easy install, I didn't have an idea what was going on.
 
throAU said:
Instead of having some sensible defaults like that (...)

FreeBSD is not starting services by default, and I'm grateful for that.

At least you are forced to know _at minimum_ what are doing.
 
morbit said:
FreeBSD is not starting services by default, and I'm grateful for that.

At least you are forced to know _at minimum_ what are doing.

I'm not saying start, or even install things by default.

But if i want to build a box to perform a particular role, then there should be some sort of sensible default way of doing it, with a sensible example configuration.

I mean, lets take sendmail for example. Pretty common task for a unix box right?

If I was to give 5 different users 1 hour to come up with a sensible smtp configuration for a small single site, we'd end up with 5 different sub optimal configurations. Depending on the skill level, some wouldn't even manage a working configuration in that time, let alone one with sensible grey-listing, anti spam features turned on (greet delay, etc.), DNS block lists, etc.

Again, not FreeBSD specific, but a common unix problem....

Email is (or should be) a basic, cookie cutter task for the vast majority of systems. Insert IP range to relay for here. Insert local domains to accept here. Insert domains to relay for here. Would you like anti-spam enabled? Yes/no. That's as hard as it should be to get something sane. If you have special requirements, tweak the file yourself...


Sure, the current way is the status quo and how unix has been for decades. It's not good enough.
 
Status
Not open for further replies.
Back
Top