# FreeBSD - a lesson in poor defaults



## freezr (Aug 18, 2022)

Found this article on Mastodon...



			FreeBSD - a lesson in poor defaults
		


I don't have enough knowledge to say is wrong or right, but many of you have it so it may generate a lot of interesting opinions!

Look forward to read your thoughts!


----------



## msplsh (Aug 18, 2022)

I think the last thread about this link got deleted.


----------



## eternal_noob (Aug 18, 2022)

Cencorship? In this forum? I can't believe it! 

Anyway, thanks for the link, bookmarked.


----------



## drhowarddrfine (Aug 18, 2022)

Not this again. It's outdated. Misdirected. Opinionated. And flat out wrong in some areas.


----------



## richardtoohey2 (Aug 18, 2022)

Some discussion (including how it is several years old) on lobsters: https://lobste.rs/s/2xxp8y/freebsd_lesson_poor_defaults


----------



## kpedersen (Aug 18, 2022)

I think the following snippet of the authors proposed sysctl.conf is a good example:


```
security.bsd.hardlink_check_gid=1  # These two options will break poudriere's
security.bsd.hardlink_check_uid=1  # compiling privsep.
```

Is he saying that something that specifically breaks poudriere should be the default instead? Bizarre. I am going to assume his suggested "default" candidate would change if he was a pourdriere user. But that isn't what a "default" is!

Seems to be just another guy online who is not very able to reflect upon the fact that tweaks for them don't match the use-case of others. This is along the same lines as GUI installers, default text editors, etc. Since a true "default" can't be made, we just stick with what is already there to avoid breakage.


----------



## drhowarddrfine (Aug 18, 2022)

Here's Ed Maste from the FreeBSD Foundation:


> This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there’s also information that’s so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.


----------



## edthesmokebeard (Aug 19, 2022)

Oh lord not this again, this was just posted over on Reddit.


----------



## msplsh (Aug 19, 2022)

eternal_noob said:


> Cencorship


Bad (reaction) behavior.


----------



## Crivens (Aug 19, 2022)

msplsh said:


> Bad (reaction) behavior.


That, and we would rather not create the impression that we endorse that content. 
It is also controversial, and leads to heated debates over facts, habits, heritage and maybe smells.


----------



## drhowarddrfine (Aug 19, 2022)

edthesmokebeard said:


> this was just posted over on Reddit.


Which verifies the gutter quality of the piece. Only reddit would stoop so low.


----------



## tux2bsd (Aug 19, 2022)

Like these forums, Reddit are also a censorious bunch.

Here's an idea.  Why don't you take that article, turn it into a wiki page (_a reponse to xyz_) and update and correct whatever needs correction.  Just don't hide what you don't like... this aspect is something you "party faithful" certainly won't want to entertain.


----------



## Alain De Vos (Aug 19, 2022)

For who might be interested my sysctl.conf,

```
###ENABLE SECURITY 
security.bsd.unprivileged_read_msgbuf=0  #1 
security.bsd.unprivileged_proc_debug=0   #1 
kern.randompid=1                         #0 
kern.sugid_coredump=1                    #0 changed credential programs dump core  
kern.corefile=/var/coredumps/%U/%N.core  #%N.core 
###KERN 
kern.msgbuf_show_timestamp=1             #0 show timestamp in messagebuf 
kern.shutdown.poweroff_delay=2000        #5000 : Delay before poweroff to write disk caches (msec) 
kern.shutdown.kproc_shutdown_wait=20     #60 : Max wait time (sec) to stop for each process 
kern.ipc.shm_use_phys=1                  #0  : Enable locking of shared memory pages in core 
kern.ipc.shmall=512000                   #131072 
kern.ipc.shmmax=1000000000               #536870912 
###HW 
hw.usb.no_shutdown_wait=1                #0  : No USB device waiting at system shutdown 
###VFS 
vfs.zfs.min_auto_ashift=12               #9 
vfs.usermount=1                          #0,Unprivileged users may mount and unmount file systems 
##################987654321#### 
vfs.zfs.arc_min= 1500000000              #0 
vfs.zfs.arc_max= 2500000000              #0 
#################a987654321### 
###NET################################################################## 
net.inet6.ip6.temppltime=7200            # 86400 ,  Maximum preferred lifetime for temporary addresses 
net.inet6.ip6.tempvltime=14400           # 604800 , Maximum valid lifetime for temporary addresses 
net.inet.tcp.cc.algorithm=cubic          #newreno #Congestion control newreno,CDG,CHD,CUBIC,DCTCP,HD,H-TCP,VEGAS 
# 
net.inet6.ip6.redirect=0                 #1 
net.inet6.icmp6.rediraccept=0            #1        
net.inet.ip.redirect=0                   #1 
net.inet.icmp.drop_redirect=1            #0 
# 
net.inet.ip.maxfragpackets=0             #15762 
net.inet.ip.maxfragsperpacket=0          #16 
# 
net.inet.tcp.blackhole=2                 #0 
net.inet.udp.blackhole=1                 #0 
# 
net.inet.tcp.always_keepalive=0          #1           
net.inet.tcp.nolocaltimewait=1           #0            
net.inet.tcp.icmp_may_rst=0              #1 
net.inet.ip.check_interface=1            #0                   
net.inet.ip.process_options=0            #1                   
net.inet.ip.random_id=1                  #0                           
net.inet.icmp.icmplim=50                 #200 
#aslr 
kern.elf64.aslr.enable=1                 #0 
#aslrpie 
kern.elf64.aslr.pie_enable=1             #0 
# 
net.inet6.ip6.accept_rtadv=1             #0 Default value of per-interface flag for accepting ICMPv6 RA messages 
# 
kern.metadelay=4                         #28 
kern.dirdelay=5                          #29 
kern.filedelay=7                         #30 
# 
security.bsd.unprivileged_idprio=1       #0 
kern.sched.preempt_thresh=120            #80
```


----------



## msplsh (Aug 19, 2022)

tux2bsd said:


> Why don't you take that article


Elevates it to a position nobody wants.

Minor example: TCP wrapper "point" doesn't actually... have one?


----------



## astyle (Aug 19, 2022)

There's always gonna be somebody who doesn't like the defaults... there's several outtakes from that:

There's no such thing as a 'perfect' setup.  FreeBSD ships with minimum needed to have a working system, but then it's up to the user to put in the effort to set the system up as they see fit.
The article was last updated 6/23/2022.
Yeah, the article is laced with commentary about how the defaults don't make sense for the author/user.
Once you get past the author's disdainful attitude, they do bother to make the case by pointing out technical details. 
In post #7, drhowarddrfine dug up a very good response from FreeBSD foundation. I see that response as a sign that somebody from the Foundation actually bothered to read the whole article, and formulate a thoughtful response. 
Most negative responses to the article seem to come from readers who just skimmed the article, caught an 'off-putting point A' about it - and off-handedly said that the whole article is crap because of that one point A. The article has more than just the unlikeable 'Point A', people!


----------



## mer (Aug 19, 2022)

astyle said:


> Once you get past the author's disdainful attitude, they do bother to make the case by pointing out technical details.


Oftentimes a point is better received for discussion if not presented with disdain.
Your previous point about the "defaults not making sense for the author" is a key point to me.  The problem is that led into a lot of his attitude, presenting as "he knows better than any other user so noone should question his word".  He did not state that, but that is what came through.
I personally think some of the items warrant discussion, but feel there was a lot of "I don't like the defaults because they don't fit the way I think they should be" (like the things about periodic.conf, rc.conf and firewalls).

I saw the date of last edit, but I wanted to know "what was updated/changed" and it was effectively "sleath edit".  I think he should have kept the previous iterations, then mark updates clearly as to what has changed.


----------



## freezr (Aug 19, 2022)

I promise I won't post anymore opinionated articles randomly found in the Fediverse...


----------



## mer (Aug 19, 2022)

freezr said:


> I promise I won't post anymore opinionated articles randomly found in the Fediverse...


My opinion, that is the wrong thing to take away from everything folks have said here.
The saying "a broken clock is right twice a day" applies to the link you posted.
The problem is, just like trying to discuss say politics with someone, if you start the discussion with a "you are stupid your opinion is stupid" attitude, you basically lose.  You are not having a discussion, you are giving/getting a lecture.


----------



## astyle (Aug 19, 2022)

freezr said:


> I promise I won't post anymore opinionated articles randomly found in the Fediverse...


Most blogs/articles about technology and 'best practices' have some have some degree of narcissism to them. You gotta be able to look past that to be able to get solid technical information from such sources. 

I personally think that there's nothing wrong with discussing the said articles/blogs in here, but there's kind of a format/template to how those discussions are *started* and *conducted*.  I'd suggest thinking about a few things, such as: why you're starting a discussion, what you think of the article, what the outtake is... Nothing formal, but don't be lazy, put some thought into it. And the FreeBSD forums do have mods who can step in if the conversation gets out of hand.


----------



## Crivens (Aug 20, 2022)

astyle said:


> I personally think that there's nothing wrong with discussing the said articles/blogs in here,


Discussions and corrections are welcome. Only the mud slinging contests are unwelcome, at least here. And I think at the original source also, or they would allow for comments? So someone posts some content, does not allow to be critizised (need to be right, save public face) and thus offloads the 'discussions' to other places. 
Is it only me or is this akin to dump your trash in the woods?

So be polite and bring facts so we can have a discussion. Be rude and you get shown the door. This is not censorship, this is the rules of the house.


----------



## tux2bsd (Aug 20, 2022)

Whatever, Crivens.  You'll employ the tried and true "_that was rude_" to apply your censorship (which includes locking discussion, not only removing it).


----------



## zirias@ (Aug 20, 2022)

astyle said:


> I personally think that there's nothing wrong with discussing the said articles/blogs in here


Concerning _this_ specific article, I don't think it's worth discussing it any more. It's been around for a very long time, and it was "discussed" a lot. Still the result is the same. Some claims are just wrong, most are just personal opinion (with sometimes complaining the default isn't the "most secure for any scenario choice" as OpenBSD would do, and some with questionable secuirty implication at all). Between all this, there are a few valid complaints (although last time I checked, some of _these_ were already outdated in spite of the author claiming regular updates). It's a well-known strategy to mix in some well-founded points in your opinionated work, that way, readers are easily tricked into taking the whole thing seriously.


----------



## hardworkingnewbie (Aug 20, 2022)

That article is the result if you want FreeBSD to become more like OpenBSD, a lot, while there are enough reasons around why FreeBSD will never be that way. 

It's the equivalent of a BMW lover complaining about that Mercedes should be more like BMW, which will never happen for obvious reasons. And vice versa. There's a variety of BSDs and other stuff out there for good reason - different needs, different tool.


----------



## mer (Aug 20, 2022)

hardworkingnewbie said:


> That article is the result if you want FreeBSD to become more like OpenBSD, a lot,


I think it's important to add this:

"out of the box"

Nothing prevented the author from applying changes to his default FreeBSD install to achieve his goal.  Heck if he feels that strongly about it, perhaps he should take a look at something like HardenedBSD or try getting a port added that simply applies his desired settings.


----------



## wolffnx (Aug 20, 2022)

Yes,there are many bad opinions to FreeBSD but the encrypted swap was right,is important to encrypt it
I check it with his example


----------



## drhowarddrfine (Aug 20, 2022)

hardworkingnewbie said:


> if you want FreeBSD to become more like OpenBSD


Which is a reason why "Why isn't FreeBSD more like..." questions aren't allowed here.


----------



## eternal_noob (Aug 20, 2022)

Rather, "Why isn't FreeBSD more secure?".  And this question should be allowed.


----------



## drhowarddrfine (Aug 20, 2022)

eternal_noob Yes but it's a misleading question prone to argument. A better question would be, "How can I make my installation more secure?"


----------



## zirias@ (Aug 20, 2022)

eternal_noob said:


> Rather, "Why isn't FreeBSD more secure?".  And this question should be allowed.


That's a gross over-simplification, and a sign the narrative of that "article" got through.

Security is never an absolute thing. It depends on specific threats, risk analysis, etc.

Let's just pick two examples:

In this very thread, someone agreed that "swap should always be encrypted". Really? What's the threat here? Clearly, it's hardware falling into the wrong hands. When that happens, encrypted swap helps keeping private things secret. But what if that isn't even a realistic scenario for you? A bad thing that _can_ happen with encrypted swap on FreeBSD is a resource deadlock (as GELI sometimes needs to dynamically allocate memory) in situations of _heavy_ memory pressure. Although unlikely, I experienced that during a massive poudriere bulk run. And of course, it always costs a tiny bit of computing power. So, it's a trade-off.

Other example, this article states that intel's hyperthreading *must* be disabled by default (btw, it is on OpenBSD). Looking at the threat again: side-channel attacks. Especially relevant when running virtual machines operated by potentially untrusted parties. Potentially relevant on any "shared" system. But nowhere near the immediate threat of e.g. some remote vulnerability. Whether you *must* disable it very much depends on your scenario. In this case, disabling it will cost you almost half of your processing power.

FreeBSD is not OpenBSD. OpenBSD will always pick defaults, so they are secure in _any_ scenario you could think of (and still, even OpenBSD can't magically protect you from any vulnerability found in some software). FreeBSD prefers for example not to impair performance for everyone by default, not to break things without warning, etc.

If you think picking defaults "the OpenBSD way" is the only correct way, then, well, just use OpenBSD.


----------



## getopt (Aug 20, 2022)

zirias@ said:


> Other example, this article states that intel's hyperthreading *must* be disabled by default


But in the article can be read:


> Intel's hyperthreading technology (also known as SMT, Simultaneous MultiThreading) has proven itself to be insecure, so it *should* be disabled here.



From RFC 2119:


> MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
> definition is an absolute requirement of the specification.
> 
> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> ...


----------



## zirias@ (Aug 20, 2022)

Ah, well. As already stated in a private message concerning this, "_should_" wouldn't really describe what the author of this article means.

To understand it, you probably have to read the whole article. Then, you will understand (e.g. through "stylistic" elements like sarcasm) that this author truly believes their views are the only correct ones. They don't use words like "must" a lot, and they use "should" and similar quite often, but that can't hide the intentions. (It is OTOH a nice stragety to enable "Wortklauberei" like this later)

I didn't _cite_ the article. I reproduced part of its contents in my own words. Reproducing the word "should" there would only make it less accurate.

*edit:* BTW, citing some definitions obviously taken from formal specifications (if I'm not mistaken they might come from IETF) here is very off-topic. We're really not talking about formal language here, to the contrary.


----------



## hardworkingnewbie (Aug 20, 2022)

zirias@ said:


> In this very thread, someone agreed that "swap should always be encrypted". Really? What's the threat here? Clearly, it's hardware falling into the wrong hands. When that happens, encrypted swap helps keeping private things secret. But what if that isn't even a realistic scenario for you? A bad thing that _can_ happen with encrypted swap on FreeBSD is a resource deadlock (as GELI sometimes needs to dynamically allocate memory) in situations of _heavy_ memory pressure. Although unlikely, I experienced that during a massive poudriere bulk run. And of course, it always costs a tiny bit of computing power. So, it's a trade-off.


Obviously the threat model with unencrypted swap is that cryptographic keys could be stored in it unencrypted, and if somebody switches power off could peel them out of the swap space. Encrypted swap space might help against this. 

Then again, it's known since two decades by now that modern RAM hardware does not lose data after power loss immediately, but over time. And if you cool it down, then you can peel that data out of the RAMs instead. So encrypted swap obviously cannot protect against this sort of attack.






						Cold boot attack - Wikipedia
					






					en.wikipedia.org


----------



## zirias@ (Aug 20, 2022)

hardworkingnewbie said:


> Obviously the threat model with unencrypted swap is that cryptographic keys could be stored in it unencrypted


That's just one specific example of something that should stay secret (of course, an important one!). But to make it a threat, someone unauthorized must gain access to the hardware.


----------



## mer (Aug 20, 2022)

zirias@ said:


> Security is never an absolute thing. It depends on specific threats, risk analysis, etc.


Yes.  This.  Upvote a million times as all the cool kids nowdays say (I think.  I'm old, so I don't know).

CVEs:  It's always good practice to read them and try and understand them, simply because it makes one aware of potential threats.  As a sysadmin you then determine if they apply to the systems you are responsible for.  Part of that is determining "criticality" of the CVE or "how soon do I need to patch or mitigate on my systems".

There are some that sound scary, but when you read it and they say "must have physical access to the system in order to reboot it and hit this key combination 12 times during the loader" well, that can be lower on the critical list or deferred.
Remote execution gain root through web server frameworks?  Immediate action IF the system is actually serving web stuff.

Sendmail:  home of the original remote exploit (Thank you Robert Morris for a worm).  Yes, lots of CVEs over the years, but in the default configuration after a new install is it really a concern?  Long time since I've done an install but I thought it defaulted to local host only delivery out of the box, which as an exploitable footprint is pretty small.

Discussions about security are never a bad thing as long as "religious" positions are not taken.  IPFW vs pf  lots of good discussions can be had but have to start from the same point:  what are the requirements for THIS system.  

A lot goes back to my earlier comment about how information is presented.  Even the most contentious, presented properly will lead to fruitful discussions.  Present it wrong (typically "my way or the highway" or "you are just to stupid to understand what I'm saying") and things come across as trollish.

As for the article itself, there are some good points in it, some that I disagree with because they don't fit my needs/systems, some that are in the middle that are up for discussion.


----------



## zirias@ (Aug 20, 2022)

mer said:


> As for the article itself, there are some good points in it


Just out of curiosity (and, maybe, there _is_ something to discuss), which are these? Are these points that weren't already adressed (like, e.g., being able to build ports as non-root, that works...)?


----------



## eternal_noob (Aug 20, 2022)

zirias@ said:


> That's a gross over-simplification, and a sign the narrative of that "article" got through.


That's a sign for nothing, i tend to over-simplify things, but this is me. I didn't even read that article.


----------



## zirias@ (Aug 20, 2022)

eternal_noob said:


> i tend to over-simplify things, but this is me.


Looking at your avatar, this comes a little unexpected . Well, then I misinterpreted your reaction, that's great .


----------



## eternal_noob (Aug 20, 2022)

zirias@ said:


> Looking at your avatar, this comes a little unexpected


I thought that logic WAS simple.


----------



## mer (Aug 20, 2022)

zirias@ said:


> Just out of curiosity (and, maybe, there _is_ something to discuss), which are these? Are these points that weren't already adressed (like, e.g., being able to build ports as non-root, that works...)?


For me personally, some of the sysctl settings I thought were interesting (to me) like some of the network settings for security, the pkg stuff, well even Ubuntu you have to at least sudo if you actually want to install or upgrade.  
SSL/TLS stuff:  interesting (to me) but at work we run into issues where having fielded systems not yet upgraded you need  the deprecated values sometimes if you want to talk to them and actually upgrade.  If something is browser based and your browser deprecates some stuff (Chrome and Firefox have both done this) you wind up not being able to talk to a fielded system so you can upgrade it.
Compile time options, well they only matter if you are actually compiling.

So for me, changes in sysctl were the ones personally interesting, mostly because I routinely set some of them on my systems and have for a while, so should they be defaulted?  I don't know, my bias is "no", but perhaps better documentation around them would help.


----------



## tux2bsd (Aug 20, 2022)

zirias@ said:


> But to make it a threat, someone unauthorized must gain access to the hardware.


Not only the hardware, that just makes things easier.  Access to the operating system (with a current or future method to elevate to root, however that may be achieved).


----------



## edthesmokebeard (Aug 21, 2022)

tux2bsd said:


> Like these forums, Reddit are also a censorious bunch.
> 
> Here's an idea.  Why don't you take that article, turn it into a wiki page (_a reponse to xyz_) and update and correct whatever needs correction.  Just don't hide what you don't like... this aspect is something you "party faithful" certainly won't want to entertain.


This is the answer.  But its far easier to drag out 20 year old sendmail vulnerabiltiies.


----------



## edthesmokebeard (Aug 21, 2022)

wolffnx said:


> Yes,there are many bad opinions to FreeBSD but the encrypted swap was right,is important to encrypt it
> I check it with his example


I see no basis for this.   If someone has your physical machine, all bets are off.   There might be no reason NOT to encrypt it, but it's hardly universal that 'its important to encrypt it".


----------



## edthesmokebeard (Aug 21, 2022)

zirias@ said:


> Ah, well. As already stated in a private message concerning this, "_should_" wouldn't really describe what the author of this article means.
> 
> To understand it, you probably have to read the whole article. Then, you will understand (e.g. through "stylistic" elements like sarcasm) that this author truly believes their views are the only correct ones. They don't use words like "must" a lot, and they use "should" and similar quite often, but that can't hide the intentions. (It is OTOH a nice stragety to enable "Wortklauberei" like this later)
> 
> ...


Then that's the fault of the author.   If he wants to be taken seriously, he needs to write seriously.


----------



## mer (Aug 21, 2022)

edthesmokebeard said:


> I see no basis for this.   If someone has your physical machine, all bets are off.   There might be no reason NOT to encrypt it, but it's hardly universal that 'its important to encrypt it".


Disk encryption in general, in my opinion, can be overused.  One thing people forget or gloss over is that encryption only protects cold disks or unmounted partitions.  Machine up, devices/partitions mounted, the data is vulnerable.  I also question "why do people encrypt the entire disk?"  Is there really anything in /etc that needs to be encrypted?   That's my opinion and I'm going to tell anyone they're wrong for doing it their way.


----------



## zirias@ (Aug 21, 2022)

mer disk encryption is useful. Once again, it depends on your threat model. You're completely right, it does nothing for you on a running machine. I think that's the main problem with both the article discussed here, and how people discuss it. It's a fundamental misunderstanding that any single "security measure" could ever be something "everyone needs". It's OpenBSD's "mission statement" to deliver a system that's as secure as possible out of the box for _any_ scenario (and if that scenario doesn't apply to you, you have to change settings e.g. in order to get better performance). FreeBSD defaults focus on a more "generic" view. Still, you can change what you don't like.



tux2bsd said:


> Not only the hardware, that just makes things easier.  Access to the operating system (with a current or future method to elevate to root, however that may be achieved).


Encrypted swap won't help with this. On a running machine, there will be a "mapped" device allowing access to the unencrypted data.


----------



## Profighost (Aug 21, 2022)

mer said:


> Disk encryption in general, in my opinion, can be overused.


depends on:
- the machine you use
- the concerned data
- your personal attidude between careless and paranoid

In german we have a saying:
"Opportunity makes thiefs"
Even the worst lock is better than none.

On my desktop pc the disks are not encrypted.
I keep sensitive data in several encrypted files, containers, archives.
For the rest anybody gets physical access to the machine (and knows FreeBSD) can get to anything.
But he/she needs to break in my home first.

On my laptop the entire disk is encrypted.
Cause it can be stolen or get lost.
And it's just less effort to enter the password once at booting, than handle with encryption/decryption all the time.

What are you doing, if you find a lost USB flash drive on the street?
You'll take a peek what's on it, of course 
If the stick would be encrypted - even with something light every noob-hacker would laugh about -
you'd consider: is it worth the effort or do I just format it?


----------



## mer (Aug 21, 2022)

Profighost said:


> depends on:
> - the machine you use
> - the concerned data
> - your personal attidude between careless and paranoid


Yep, that's why I said "My opinion" and "in general".  Too many people (corporations) simply say must encrypt everything all the time without thought on "who, what why"  that is the part I've always disagreed with.  Encrypt separate devices/partitions hold financial data?  Absolutely a good idea.  The CFO laptop that he takes with him on the train, to meetings?  Yep likely candidate for whole disk encryption.  The shared family PC?  Not the right choice (my opinion) but mom & dad should have a separate data disk encrypted having the family finances on it.

I don't think I was clear enough:  I don't disagree with disk encryption, but blindly doing whole disk encryption without thinking is what I disagree with.



Profighost said:


> On my laptop the entire disk is encrypted.
> Cause it can be stolen or get lost.
> And it's just less effort to enter the password once at booting, than handle with encryption/decryption all the time.


And that is pretty much the exception to my opinion:  laptops that travel or could be easily stolen.



Profighost said:


> What are you doing, if you find a lost USB flash drive on the street?


Me personally?  Look to see if there is any identifying info on it so I can return it, otherwise toss it in the trash.  Easy way to get someone to start loading malicious stuff on your computer.


----------



## Crivens (Aug 21, 2022)

mer said:


> Is there really anything in /etc that needs to be encrypted?


Maybe not. But in /bin or /sbin for sure. Encryption ensures that no one tamperes with f.e. login while your system is down to slip you a souped up one.


----------



## hardworkingnewbie (Aug 21, 2022)

edthesmokebeard said:


> Then that's the fault of the author.   If he wants to be taken seriously, he needs to write seriously.


If that author really would have wanted to be taken seriously, he would have stated his name in the file like it is good common practice for various reasons. He didn't.

With a little bit of research it's no secret who created that file: somebody going by the pseudonym of TJ or blakkheim, a former producer of the BSDnow podcast.

But still - not in the file nor homepage, which speaks volumes by itself.


----------



## mer (Aug 21, 2022)

Crivens said:


> Maybe not. But in /bin or /sbin for sure. Encryption ensures that no one tamperes with f.e. login while your system is down to slip you a souped up one.


That would be a bit easier than read only media for the system files, or doing mtree stuff during boot or "TPM" type of stuff.

Writing under a pseudonym is a long standing tradition, probably started as soon as there were cave drawings.  

I don't necessarily think it's a bad thing, but my opinion (again, mine, agree, disagree, all good to me) is if one is going to write an article/book/paragraph criticizing something, you should own up to it.  It's like restaurant or product reviews:  very easy to leave a negative one without ever having eaten there or used the product. Let's face it, we are all human (I know I'm assuming a lot about myself and others here) and we have biases and preferences.  Just because something doesn't work the way "I" want it to out of the box doesn't mean it's garbage, heck pick your favorite desktop environment or window manager.  50% love it, 50% hate it, the other 27% are undecided.  So a critical review of anything should be owned up to, simply for readers to be aware of potential bias.  The bias itself isn't wrong, it is simply a fact that indicates why the author may say what they do.

If everyone agreed on everything why bother getting out of bed?


----------



## Profighost (Aug 21, 2022)

To mer's last post I'd like to add another pure notional idea:
Since to me the number of threads here seem to increase wherein FreeBSD's downsides are shown,
not seldom anonymous, by naming neutral attributes as a downsize, and adding things artificially up to look even worse,
and also the numbers of newcomers to FreeBSD seem to increase (I don't know - it just feels to me like that, would be a good thing.)
while other OS, especially Linux, seem to have made decisions aggrieving parts of their communities,
it may occur to me the one or the other just come here to libel and slander as some kind of anti-advertisment make to FreeBSD look bad.

After all, one may post anything on the internet, anonymous and completely without any liability.
There are always many people disussing it, no matter what.
For many people it's proof enough when they hear someone else independently talk about the same issue.
An insubstantial rumour alone can be enough to ruin something, just because people won't stop talking about it.

Short:
Anybody can create an account and post "FreeBSD zfs destroys harddisks".
Doesn't matter if it's pure bs.
Doesn't have to be something that obvious, something a bit better - lot of real Pros are active here - but you'll get my point.
You'd have a discussion about that here.

And even if the Pros are relaxed, because they are aware of what FreeBSD can do, and what's bs,
newbies are rattled.

So again, as Hardworking newbie, me and others already pointed out:
If it's anonymous, don't take it serious at all.


----------



## mer (Aug 21, 2022)

Trolls.  Ruining everything.  The "best" trolls include a small bit of truth or half-truth.



Profighost said:


> And even if the Pros are relaxed, because they are aware of what FreeBSD can do, and what's bs,
> newbies are rattled.


This is a big part of the problem.  Anyone with enough experience can see the bs, and rightfully gets upset "Geez, not this crap again".  Trying to explain all that to newbies "why that is bs" comes across as being defensive.  Ignoring comes across as "Oh, they have nothing to say so it must be true".  Trying to go point by point gets too long and people don't read the whole thing.  Another big part is some things seem to come up periodically and the "Pros" get frustrated around the fourth time it comes up.

So what do we do?  I don't know anymore.  Explain, acknowledge, refute point by point and don't get personal.  After that, walk away from the keyboard, go have a beer a coffee, take a deep breath.


----------



## Profighost (Aug 21, 2022)

Not much, really.
Except trying to let bs-threads die quickly (sorry for posting again, but we're some kind off topic in a good will )
and keep on producing confidence and


mer said:


> Explain




In Terry Pratchett's Discworld novel _The Truth_ is a saying:
"A lie can run around the world before truth has put on her boots."


----------



## mer (Aug 21, 2022)

I think if we get too far off, the mods will come along, cane us both and then lock the thread.


----------



## Crivens (Aug 21, 2022)

Caning is so yesteryear... *puts Justin Biber CD on*


----------



## msplsh (Aug 21, 2022)

Where's OP anyway, just wanted to set off this bomb and leave?


----------



## astyle (Aug 22, 2022)

Crivens said:


> Caning is so yesteryear... *puts Justin Biber CD on*


* Streams Crivens '  CD in FLAC format on an Iridium 9555 phone


----------



## Crivens (Aug 22, 2022)

astyle said:


> * Streams Crivens '  CD in FLAC format on an Iridium 9555 phone


I did not press Play - yet 
And you will look at your phone contract before you do this, yes?


----------



## Profighost (Aug 22, 2022)

Crivens said:


> Caning is so yesteryear... *puts Justin Biber CD on*






msplsh said:


> Where's OP anyway,


That's also something very important many are not aware off (keeping on discussin, turning around themselves.)
One have to keep an eye on exactly for this best sign.


----------



## hardworkingnewbie (Aug 22, 2022)

mer said:


> So what do we do?  I don't know anymore.  Explain, acknowledge, refute point by point and don't get personal.  After that, walk away from the keyboard, go have a beer a coffee, take a deep breath.


Future standard behaviour could be to just link this thread to the new one with that opinion piece, and then fade it out by not answering any more to the new one.


----------



## Profighost (Aug 22, 2022)

hardworkingnewbie said:


> uture standard behaviour could be


Good idea.
Better to have something official like "Why is FreeBSD not more like...".
_BUT _
problem is, when you are aware of trolling, it's already too late...
According to several sites it's an old, known problem,
and there is no real solution.
Except - and this ain't no good idea for this one here - you have a closed forum.


----------



## tux2bsd (Aug 22, 2022)

You chief whingers could simply ignore the thread, there's an unwatch button.



zirias@ said:


> Encrypted swap won't help with this. On a running machine, there will be a "mapped" device allowing access to the unencrypted data.


Correct.  Congratulations on choosing to ignore the point of the previous comment.


----------



## angry_vincent (Aug 22, 2022)

Profighost said:


> To mer's last post I'd like to add another pure notional idea:
> Since to me the number of threads here seem to increase wherein FreeBSD's downsides are shown,
> not seldom anonymous, by naming neutral attributes as a downsize, and adding things artificially up to look even worse,
> and also the numbers of newcomers to FreeBSD seem to increase (I don't know - it just feels to me like that, would be a good thing.)
> ...


that's what last decade phenomenon is -- everyone appears to be the ones, who generating the knowledge, instead of natural way of acquiring knowledge, with iterations and improvements of one self journey through the bits of information. you can create whatever hilarious blog, article, opinion on any subject and it then multiplied and spreading forth by power of search engines and various information channels all have access too. my personal observation on this.


----------



## drhowarddrfine (Aug 22, 2022)

I've said this here before:
The best thing about the internet is that everyone has a voice.
The worst thing about the internet is that everyone has a voice.


----------



## DutchDaemon (Aug 22, 2022)

Thanks for another round of debugging said article. Moving right along.

</locked>


----------

