Twitter | Search | |
RhodiumToad
Find me on IRC: or on . (he/him)
182
Tweets
19
Following
140
Followers
Tweets
RhodiumToad Jan 21
Somehow this B5 quote seems applicable: "Cannot run out of time. There is infinite time. You are finite. Zathras is finite. This ... is wrong tool."
Reply Retweet Like
RhodiumToad Jan 8
Replying to @alex_lipov @b0rk
In the mountpoint case, the lookup first traverses into the mounted-over directory, and then looks up the '..' entry in that instead
Reply Retweet Like
RhodiumToad Jan 8
Replying to @alex_lipov @b0rk
It's up to the lookup function (traditionally called namei()) to detect two special cases for '..': the current process root dir, and mountpoints
Reply Retweet Like
RhodiumToad Jan 8
Replying to @MengTangmu
No.
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
It's building fine with no -j option at all, too.
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
df98052635bc68db2c3097a00cf68ca7 For reference, this is the src tree installed from the 12.1 distribution image
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
If it's not behaving consistently (assuming you're not using meta mode, or you empty /usr/obj first) then I'd start wondering about hardware issues.
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
Using -j2 at 1GB, build is still running but has built AST/Dynamic/Registry successfully. swap high water mark about 300MB so far. (I'll try -j1 after this is done, but obviously that'll take longer)
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
Build completed w/o error on 3GB; trying again on 1GB at lower -j settings.
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
SIZE on compile of some files (including the one you mentioned) does go over 600-700MB on 64-bit systems; also some of the link commands may need significant memory. For zfs on 1GB you may need to significantly reduce ARC limits
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
That does not seem plausible.
Reply Retweet Like
RhodiumToad Dec 17
Replying to @extremecompute
Can't reproduce. Installed a 12.1 system with zfs in a 3GB bhyve vm, and tried a buildworld at -j4; it's still running (maybe ~45 min to go), but it compiled that file ok
Reply Retweet Like
RhodiumToad Dec 16
Replying to @kdedude @p4tpr0 and 3 others
It doesn't even build cleanly as-is (QPrinter errors) - I made a working port by stealing a patch from another OS's packaging. I can contribute the port I have, if there's interest, but I will not take maintainership.
Reply Retweet Like
RhodiumToad Dec 16
Replying to @FreeBSDHelp
Got it to fetch and configure, but the build fails for what looks like a QT problem (an include which I think should be needed is ifdef'd out). I have no prior experience with QT, not sure if I'll have the time to dig into it
Reply Retweet Like
RhodiumToad Dec 16
Replying to @FreeBSDHelp
The version in ports was from 2010, there's a 2013 version that supposedly has qt5 support. But I think the only way to get the distfile is from a snapshot tarball from sourceforge (not a release) so it'll require some fiddling to get.
Reply Retweet Like
RhodiumToad Dec 15
Replying to @extremecompute
If you have sufficient swap space but still get OOM kills that DON'T have a "swap_pager_getswapspace" error, also try increasing vm.pageout_oom_seq a lot. (OOM kills can be triggered not by lack of swap space but by slowness in pageouts)
Reply Retweet Like
RhodiumToad Dec 15
Replying to @extremecompute
If you're using poudriere, then consider disabling or reducing tmpfs use - llvm uses both lots of disk space (and therefore mem/swap if tmpfs is used) and lots of working RAM for compile/link.
Reply Retweet Like
RhodiumToad Dec 14
Also, bad idea to use a starting point before 1753 (or later in some parts of the world) unless you know how your calendar routines behave with old dates
Reply Retweet Like
RhodiumToad Dec 13
The correct frequencies, for any 400-year period, are (Sun .. Sat): 687, 685, 685, 687, 684, 688, 684 You could have noticed Christoph's error by the fact that the results added up to an odd number.
Reply Retweet Like
RhodiumToad Dec 13
Replying to @df7cb @PostgreSQL
Your count incorrectly includes both ends of the date range, so you're counting 800 complete years plus one day. You should instead use some (any) fixed 400-year range (the calendar repeats exactly after 400 years)
Reply Retweet Like