can anyone of you explain why omarchy.org is something that apparantley gets all of the rest of the linux world shouting "nazi"

because I just do not understand

Its just another dist isn't it?

its better funded than the rest it seems

or is it just how linux works.

BarnabasDK: people go nuts over new then it dies down

cpet: seems to me to just be another dist

a good one perhaps

I guess I just do not really understand the politics attached

and why they are attached in the first place

it actually seems to be a well thought though dist. I haven't actually tried it

based on arch - like Manjaro

So... It's Lunduke but you asked: x.com/LundukeJournal/status/2097867660885123379

omarchy was founded by an ethnic cleansing promoter, David Heinemeier Hansson

who is also big in the Ruby space

Regarding DHH: jakelazaroff.com/words/dhh-is-way-worse-than-i-thought

This is all really more suitable for #freebsd-social than here.

I've got a local unbound configuration serving up DNS for both local network as well as any clients connected via openvpn. In the past, I've had to use REQUIRE in unbound's rc.d script to ensure openvpn is started first, however, it keeps getting clobbered on updates. What is the best way to go about specifying, in a way that will stick, that openvpn needs to be started before unbound? I'm seeing a lot of "use rc.local" to manually handle all of

that, is that really the best path?

I think, not sure, that you can override /etc/rc.d/unbound with a /usr/local/etc/rc.d/unbound copy with your modifications. Then your local copy will not get overwritten on upgrades. Seems plausible.

You can check the rc script with "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" which will print out the order. So you could easily run that with the default location. Then make your modified copy in /usr/local/etc/rc.d/ and run it again and observe if it has actually replaced the system rc with your local customized rc.

rwp: since unbound is installed through pkg, not using unbound_local (or local_unbound whichever it is), the copy in /usr/local/etc/rc.d/ is what gets clobbered. And, I don't want to have that startup script out of sync if upstream ever needs to update it, is the other half of this issue.

rcorder shows unbound starting before openvpn unless I add REQUIRE openvpn to unbound, then it gets ordered after.

er, that is, the only unbound script that I use is already in /usr/local/etc/rc.d/ and not in /etc/rc.d/. And while I can and have modified the script, I want it to still get updates, but those updates clobber my changes to ensure proper ordering for my needs.

BarnabasDK: GNU/FSF are strongly political with many extreme which they pursue aggressively. that sort of thing naturally attracts people who like shouting nazi at things

not so long ago, founder of GNU and former chairman of FSF himself got to be the target of public nazi shouting

almost nobody likes shouting nazi. they are doing it a lot because there are a lot of nazis around

sounds like something a nazi would say

"people throw around calling other people nazis too haphazardly" and then an immediate "you sound like a nazi" is the lamest troll shit I've seen in a long time. Don't feed the trolls, kids.

bunni: true

maybe that's because I'm secretly a big nazi

or *maybe* I was just failing miserably at being facetious to demonstrate how immensely counterproductive it is to go around shouting nazi at things

I don't care much if GNU/FSF want to implode over that shit, but it being largely absent from BSD has enabled it to survive and thrive through the years

so, i host a few heavily modded minecraft servers on freebsd. in the age of the RAM apocalypse, and each one needing 10-20GB of ram... i've been looking for ways to reduce the ram utilization. on the IBM POWER platform, we can enable real time RAM compression, which clearly isn't an option for consumer crap like intel chips. so, any options at the freebsd level? a compressed ZFS zvol for swap came up

in my searches on the forum.

ram compression is not about consumer crap, its OS feature - the memory management needs to implement it.

well, like i said, on POWER it's hardware assisted...

but! i was just trying to figure out how to extend the ram in my freebsd box a bit further

compress for swap sounds good, if i trespass into swapping

i read something about someone using a large ram disk with compression on for swap, and causing memory to swap in and out of that often

that would make sense to save ssd from wear but saving ram ... I doubt how effective it would be.

i'm not sure how compressable it is, or how fast it rotates. i hear java 25 may have some new ram saving features

but freebsd's java doesn't have the ZGC garbage collector, so i don't know if it will have any of the newer features

and it's hard to verify

if i had a good way to tell how much of that ram was "static" vs changing, that'd be a good metric. not sure how to get that

i'd rather not swap to ssd and use up writes, but the idea of an in-memory compressed swap device was tempting, just to force idle(r) memory pages to be compressed and set aside

though i worry that more pages will be caught up in laundry

the concept of memory saving would use the fact that you could free "inactive" memory pages by storing that data elsewhere (swap or compressed pages area). and with swap, pageout/pagein is preferred to full swapout/swapin because swapout whole process to swap is slow and also that process work is interrupted (it can not work while its in swap, but it can work when only unused pages are moved off).

the problem about compression is that only compressing single page is less efficient than compressing lots of pages - if you want to keep compressed pages in memory, then you want dynamic sizing for that area, not fixed allocation you get with ramdisk. Unless your ramdisk is built as tempfs (to not reserve pages ahead).

my macos is currently reporting 11.25 GB of compressed memory (32G total)

i've had difficulty even confirming whether java is using 64k pages or not.

freebsd's docs seem to indicate that pages are dynamically sized, but i can't tell

and java doesn't report it, but it rejects or doesn't report anything when told to try to use large pages, huge pages, etc.

Hi all, AUTOCLEAN in pkg.conf(5) fully wipes the cache every single time, but pkg-clean(8) would keep some files. How do I keep the pkg cache at a manageable size, while also keeping the mental burden to a minimum? (I *don't* want to write "pkg upgrade && pkg clean" every single time: "pkg something something" should upgrade+clean -not wipe- the cache)

java has a fairly static allocation though. freebsd is only seeing spurts of 60k page faults every 10 minutes or so

illumos (solaris) pmap -xs does list Pgsz I do not know about fbsd

yeah, in aix you set some vmo params, which may be hardcoded at boot

there's been at least two separate attempts to bring page dedup/compression to fbsd vm, but both apparently failed silently

can't exactly blame them, the VM system is among the kernel subsystems I'm most confident in never being able to fully understand

yeah, i can appreciate that.

i still don't quite grasp the whole inactive vs laundry thing

i mean, this looks like there's 8G wasted in inactive...

why is the documentation so sparse about the identd (auth) facility having been absorbed into the inetd super server? The faq just states that "identd has been removed in FreeBSD 13" or something

no need to install any ports/packages

you can install oidentd from ports

the only in inetd is good enough

one*

yep. it's actually pretty good/powerful.

if you say so

you mean the protocol or oidentd

mzar, "if the administrator has forgotten about it, someone else should be hired". I disagree. Programs are written to be used by humans, and all humans make errors, whence Asimov's laws of robotics applied to software. If a compiler can detect an syntax error, it should do so rather than generating garbage.

mzar, similartly, /etc/rc.d/sshd has built in config-file check to warn the user safely, instead of applying a broken configuration.

OK

humans are fragile

"humans are fragile" -- a robot could have said so :-)

in the past there were common known cases when etcupdate(8) was breaking sshd en-mass

in happens

Yeah, and then we have the courtesy of a warning when we do `service sshd reload'.