| 00:13.55 | *** join/#devuan arnoldoree (~arnoldore@2001:d08:2060:b702:3f3e:6d29:ea5e:1d9b) |
| 00:16.30 | *** join/#devuan arnoldoree (~arnoldore@113.210.97.243) |
| 00:19.28 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 00:38.41 | *** join/#devuan epony (epony@unaffiliated/epony) |
| 00:44.56 | *** join/#devuan MetaYan (~MetaYan@c-7b5d235c.07-84-7462671.bbcust.telenor.se) |
| 00:48.51 | *** join/#devuan GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 00:50.35 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 00:50.55 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 00:51.52 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 01:15.29 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 01:39.36 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 02:02.29 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 02:07.03 | *** join/#devuan furrywolf (~furrywolf@172.58.95.105) |
| 02:26.28 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 02:37.27 | *** join/#devuan absinthe (~absinthe@unaffiliated/absinthe) |
| 02:40.29 | *** join/#devuan Uberius_ (~uberius@gateway/tor-sasl/uberius) |
| 02:43.47 | *** join/#devuan proteusguy (~proteusgu@cm-58-10-208-180.revip7.asianet.co.th) |
| 02:47.29 | systemdlete2 | libsnmp30 depends, in part, on libsensors5? Is this so mail servers can detect if a message is hot and get special priority? |
| 02:48.22 | systemdlete2 | Tell the truth. |
| 02:49.14 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 02:49.26 | furrywolf | is that commentary on excessive dependencies? :P |
| 02:49.47 | systemdlete2 | I have no idea, actually. |
| 02:55.42 | systemdlete2 | Anyone? |
| 02:56.57 | systemdlete2 | I mean, I've got plenty of diskspace, so there's no reason for me NOT to download every last package in the repo. Then I would never need to worry about missing dependencies, although upgrades would take a lot longer. With Covid-19 keeping me grounded, I've got lots of time and plenty of electricity for this. |
| 02:57.23 | systemdlete2 | Please, somebody. Talk me out of this. |
| 02:58.37 | fsmithred | talk you out of installing everything? |
| 02:58.45 | yanmaani | you'll get conflicts |
| 02:58.46 | fsmithred | Don't install everything!!! |
| 02:59.10 | yanmaani | Although I wonder what'd happen if you did sudo apt-get install -y * |
| 02:59.16 | fsmithred | install what you need. If you want to keep it lean, exclude Recommends |
| 03:00.00 | systemdlete2 | Why would libsnmp30, which I think has to do with email and email servers, depend on hardware sensors? |
| 03:00.03 | yanmaani | just gives "you've held broken packages" error |
| 03:00.10 | yanmaani | systemdlete2: look on the package info site |
| 03:00.59 | systemdlete2 | And why am I suddenly getting withheld packages? Why, what did I do? I've been faithfully updating and upgrading, minding my own business. |
| 03:01.28 | systemdlete2 | Is apt-get demanding a ransom I don't know about? |
| 03:01.51 | systemdlete2 | If I broke something, I'll pay for it, I promise! |
| 03:02.10 | *** join/#devuan nyov (~nyov@unaffiliated/nyov) |
| 03:02.11 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 03:06.21 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 03:07.52 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 03:10.15 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 03:11.32 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 03:12.50 | systemdlete2 | apt full-upgrade seems to resolve whatever issues it had. It will remove packages that would cause a conflict, which apt upgrade should be doing in the first place. Unless one prefers broken configurations I guess. |
| 03:13.33 | systemdlete2 | A package management system is useless if it does not ALWAYS enforce consistency across package dependencies. |
| 03:13.39 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 03:23.08 | systemdlete2 | yanmaani: Do you mean https://pkginfo.devuan.org/stage/beowulf/beowulf/libsnmp30_5.7.3+dfsg-5.html ? |
| 03:24.01 | systemdlete2 | Oh. My bad. |
| 03:24.08 | systemdlete2 | snmp, not smtp. |
| 03:25.17 | systemdlete2 | Still, I don't get why upgrading packages would not, by default, modify or remove or add packages as needed. It even tells you before you agree that it will be doing those things, so what is the difference? |
| 03:25.53 | systemdlete2 | Is there any reason not to use "full-upgrade" rather than "upgrade" -- will it introduce problems that plain "upgrade" will not? |
| 03:26.38 | yanmaani | systemdlete2: I recall being recommended to do upgrade first, then dist-upgrade |
| 03:26.52 | systemdlete2 | dist-upgrade does something else entirely. |
| 03:26.57 | systemdlete2 | Not what I want. |
| 03:27.06 | yanmaani | what do you want? |
| 03:27.13 | systemdlete2 | full-upgrade, it seems. |
| 03:27.48 | systemdlete2 | doesn't dist-upgrade take you to the next release level or something? |
| 03:27.57 | systemdlete2 | like ascii -> beowulf, e.g. |
| 03:28.05 | systemdlete2 | (I DON'T want that!) |
| 03:37.04 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 03:38.12 | *** join/#devuan arnoldoree (~arnoldore@2001:d08:2060:b702:3f3e:6d29:ea5e:1d9b) |
| 03:49.40 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
| 03:53.36 | *** join/#devuan pablocastellanos (~emergency@li79-248.members.linode.com) |
| 03:59.53 | *** join/#devuan nyov (~nyov@unaffiliated/nyov) |
| 04:06.03 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:37.17 | rrq | no dist-upgrade stays with the sources.list points |
| 04:37.17 | *** join/#devuan diogenes_ (~diogenes_@188.208.121.151) |
| 04:47.37 | *** join/#devuan ar3itrary (~hacker@v22016101923038440.bestsrv.de) |
| 05:06.12 | *** join/#devuan kreyren_ (~kreyren@fsf/member/kreyren) |
| 05:19.30 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
| 05:25.29 | *** join/#devuan amarsh04 (~amarsh04@2001:44b8:249:fe00:214:85ff:feee:bcc5) |
| 06:33.36 | *** join/#devuan Joril (~joril@host-217-194-188-145.sbs.redder.net) |
| 07:18.46 | *** join/#devuan cocoadaemon (~foo@88.123.134.95) |
| 07:30.31 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 08:10.23 | *** join/#devuan GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 08:22.16 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
| 08:24.07 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
| 08:28.27 | *** join/#devuan negative (b4bea72e@180.190.167.46) |
| 08:35.19 | *** join/#devuan aqu4bot (~aqu4bot@unaffiliated/subsen/bot/aqu4) |
| 09:04.18 | *** join/#devuan diogenes_ (~diogenes_@188.208.121.228) |
| 09:17.45 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 09:25.21 | *** join/#devuan rsx (~rsx@ppp-188-174-152-214.dynamic.mnet-online.de) |
| 09:43.21 | *** join/#devuan lava2 (~quassel@169-1-87-142.ip.afrihost.co.za) |
| 10:00.13 | *** join/#devuan markoong (~mark2@dynamic-adsl-78-12-137-225.clienti.tiscali.it) |
| 10:13.46 | *** join/#devuan gnu_srs2 (~srs@host-95-192-116-115.mobileonline.telia.com) |
| 10:20.31 | *** join/#devuan bz2S (~bull@185.117.72.168) |
| 10:43.08 | *** join/#devuan xinomilo (~xinomilo@gateway/tor-sasl/xinomilo) |
| 11:08.07 | *** join/#devuan diogenes_ (~diogenes_@93.116.130.26) |
| 11:13.57 | *** join/#devuan Inepu (~Mithrandi@46.234.217.137) |
| 11:19.21 | *** join/#devuan zatumil (~Administr@cgn-213-196-210-188.nc.de) |
| 11:23.00 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 11:35.10 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 13:18.04 | *** join/#devuan infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 13:18.04 | *** topic/#devuan is Welcome to Devuan! https://devuan.org | Releases: https://files.devuan.org (Beowulf 3.0 stable, ASCII 2.1 old-stable) | Forum https://dev1galaxy.org | Chanlogs http://maemo.cloud-7.de/irclogs/freenode/_devuan/ | take offtopic chat to #devuan-offtopic |
| 13:18.04 | *** mode/#devuan [+v infobot] by ChanServ |
| 13:20.27 | *** join/#devuan dagelf (~quassel@169-0-254-179.ip.afrihost.co.za) |
| 13:22.58 | *** join/#devuan cd (~cd@unaffiliated/cd) |
| 13:43.54 | *** join/#devuan Atari-Frosch (~frosch@atari-frosch.de) |
| 13:55.41 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 13:56.22 | *** join/#devuan gast0n (~g4570n@unaffiliated/g4570n) |
| 14:01.23 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:08.06 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:11.57 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:16.00 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 14:21.37 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:24.07 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:40.47 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 14:43.34 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 14:44.17 | *** join/#devuan Akuli (~akuli@mobile-access-bcee06-135.dhcp.inet.fi) |
| 14:48.26 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
| 14:54.50 | *** join/#devuan diogenes_ (~diogenes_@188.208.120.4) |
| 15:00.48 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 15:05.20 | *** join/#devuan IoFran (~Thunderbi@189.237.153.168) |
| 15:06.03 | *** join/#devuan cocoadaemon (~foo@36.161.2.109.rev.sfr.net) |
| 15:14.53 | *** join/#devuan james1138 (47240d3d@gateway/web/cgi-irc/kiwiirc.com/ip.71.36.13.61) |
| 15:21.52 | *** join/#devuan diogenes_ (~diogenes_@188.208.122.240) |
| 15:35.59 | *** join/#devuan SuaveDandy (~androirc@93-81-61-68.broadband.corbina.ru) |
| 15:37.37 | SuaveDandy | Does anyone know what "blockdevice" means in "od -j containersize - blocksize" on this ArchWiki page: https://tinyurl.com/dmcrypt-wipe ? |
| 15:38.42 | SuaveDandy | Yes, I'm wiping with dm-crypt. |
| 15:39.02 | MinceR | whatever the block device you tried to wipe was |
| 15:39.18 | SuaveDandy | *blocksize |
| 15:40.18 | SuaveDandy | Accidentally wrote "blockdevice." |
| 15:40.56 | fsmithred | SuaveDandy, there's more to exclude from my script if you want to use it. (it tries to mount stuff) |
| 15:41.23 | SuaveDandy | Ohhhhhhhh⦠|
| 15:41.31 | MinceR | dunno |
| 15:41.45 | SuaveDandy | Good that I haven't started the installation yet. |
| 15:42.37 | SuaveDandy | Do you have the lines stored at paste.debian.org ? |
| 15:42.44 | fsmithred | no |
| 15:42.59 | fsmithred | Remove lines 1113-1177 |
| 15:43.16 | fsmithred | uh, that only works if you didn't remove the other lines |
| 15:43.20 | SuaveDandy | Alright. I'll add that to my note. |
| 15:43.29 | SuaveDandy | Oh. |
| 15:43.53 | SuaveDandy | Here's the lines you gave me. https://paste.debian.net/1163235/ |
| 15:43.54 | fsmithred | from this comment: # make mount point, format, adjust reserve and mount |
| 15:44.16 | SuaveDandy | I saved it in a note-taking app. |
| 15:44.42 | fsmithred | to these lines: |
| 15:44.45 | fsmithred | mount $boot_dev /target_boot |
| 15:44.45 | fsmithred | sep_boot_opt="--exclude=/boot/*" |
| 15:44.45 | fsmithred | fi |
| 15:44.52 | fsmithred | also |
| 15:45.08 | fsmithred | you told me two volumes that are mounted at /mnt. It doesn't work that way. |
| 15:45.41 | fsmithred | I assume you have to install everything to one partition and zfs figures it out. Otherwise, I have no idea what it means. |
| 15:46.07 | fsmithred | or you move stuff manually afterward |
| 15:46.13 | SuaveDandy | ZFS uses two partitions as two pools. |
| 15:46.40 | fsmithred | if you mount two devices at the same mountpoint, you only see the second one. I can't get my head around what you're saying. |
| 15:48.18 | SuaveDandy | fsmithred: Here's the whole documentation. https://tinyurl.com/zfs-on-root |
| 15:48.24 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 15:50.37 | fsmithred | oh, you might need to add -X to the rsync command. |
| 15:50.50 | *** join/#devuan leafwiz (~leafwiz@2.79-160-198.customer.lyse.net) |
| 15:50.50 | fsmithred | I see xattr mentioned |
| 15:52.14 | SuaveDandy | What about the lines to delete? |
| 15:52.44 | SuaveDandy | Do I delete the lines you sent me before or the lines you sent me now? |
| 15:53.01 | fsmithred | both |
| 15:53.59 | fsmithred | you said you created the mountpoints and mounted everything manually, right? |
| 15:54.23 | fsmithred | that's what the second group of lines does, but not the way you want. |
| 15:55.02 | fsmithred | and just so you know, I'm not able to read that page and then tell you what you're supposed to do. |
| 15:55.09 | fsmithred | I would have to actually do it myself. |
| 15:56.58 | SuaveDandy | Alright. I'mma try using debootstrap again. This time not using --include and --exclude |
| 15:57.15 | fsmithred | that's probably easier |
| 15:57.19 | SuaveDandy | This is my last chanse. After that I give up. |
| 15:57.21 | fsmithred | less chance of having to re-do it |
| 15:58.02 | SuaveDandy | Such a shame ZFS uses CDDL. |
| 15:58.25 | SuaveDandy | We have to go through all of this because of that |
| 15:58.46 | SuaveDandy | Oracle are big meanies. |
| 15:59.46 | SuaveDandy | Although I heard it's because the OpenZFS team can't find some devs to sign for the change of license. |
| 15:59.54 | SuaveDandy | Some gone, some dead. |
| 16:09.19 | *** join/#devuan Soltis (~anon@c-73-3-82-11.hsd1.ut.comcast.net) |
| 16:14.20 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12::1e6b) |
| 16:23.25 | *** join/#devuan amesser (~amesser@p57bcfacf.dip0.t-ipconnect.de) |
| 16:26.08 | *** join/#devuan Kruppt (~Kruppt@50.111.15.137) |
| 16:27.15 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 16:29.48 | nemo | does anyone have recommendations for fixing the AMD rdrand bug on Devuan Beowulf? |
| 16:29.56 | nemo | I'm thinking I probably should be asking this in #debian |
| 16:30.04 | nemo | but figured I'd check in the channel I'm idling in first |
| 16:30.23 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 16:30.25 | nemo | followed some instructions months ago, that did not fix it |
| 16:30.40 | nemo | thankfully it is not as serious on devuan as on systemd distros. just kind of annoying in qt apps |
| 16:31.21 | *** join/#devuan leafwiz (~leafwiz@2.79-160-198.customer.lyse.net) |
| 16:32.22 | *** join/#devuan rxcomm (~rxcomm@unaffiliated/rxcomm) |
| 16:36.28 | DHE | so I run a different distro but had an rdrand issue with a ryzen 3000 series chip. openssh and openssl apps refused to work. solution was a mobo bios update |
| 16:37.07 | nemo | DHE: wut |
| 16:37.17 | nemo | DHE: openssh and openssl use rdrand exclusively??? |
| 16:37.40 | nemo | DHE: hm. maybe in Windows. I can totally see that there |
| 16:37.49 | nemo | where proper OS support for random numbers is a recent thing |
| 16:37.54 | nemo | but wait you said distro |
| 16:37.56 | nemo | DHE: which app |
| 16:38.42 | DHE | I mean not devuan |
| 16:40.12 | SuaveDandy | DHE: You run a different distro? What do you use Devuan for then? |
| 16:40.54 | DHE | right now I'm testing it in a VM for a new system |
| 16:43.36 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 16:52.00 | SuaveDandy | Ah. |
| 16:52.19 | SuaveDandy | If you've tested Debian, you've kinda tested Devuan. |
| 16:53.03 | SuaveDandy | I didn't even bother testing in VM. It's not like Arch or NixOS. |
| 16:56.46 | *** join/#devuan cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 16:56.50 | *** join/#devuan f0rs3ti (~f0rs3ti@pivpn/maintainer/f0rs3ti) |
| 16:59.37 | DHE | maybe but I hate systemd with a burning passion. in a "pour gasoline and burn it" sort of way. |
| 17:01.26 | *** join/#devuan leafwiz (~leafwiz@2.79-160-198.customer.lyse.net) |
| 17:08.58 | *** join/#devuan diogenes_ (~diogenes_@188.208.123.74) |
| 17:23.30 | *** join/#devuan _4s3ti_ (~f0rs3ti@pivpn/maintainer/f0rs3ti) |
| 17:28.36 | *** join/#devuan kreyren (~kreyren@fsf/member/kreyren) |
| 17:42.43 | *** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan) |
| 17:48.35 | nemo | DHE: can you tell me which application uses rdrand as an exclusive source of randomness? |
| 17:48.52 | nemo | DHE: or... could it be that this dubious distro uses rdrand exclusively as a kernel entropy source? |
| 18:03.52 | *** join/#devuan F_Sauce (~olav@ti0055a400-0850.bb.online.no) |
| 18:06.10 | *** join/#devuan _4s3ti_ (~f0rs3ti@pivpn/maintainer/f0rs3ti) |
| 18:06.57 | yanmaani | windows has proper os rng |
| 18:07.03 | yanmaani | vm rng is sometimes fucked |
| 18:07.04 | SuaveDandy | mason: How hard is it to maintain ZFS compared to Ext4? |
| 18:07.06 | yanmaani | in general, not windows |
| 18:08.30 | mason | SuaveDandy: Fairly easy regardless of whether you're using DKMS or custom packages. |
| 18:08.42 | mason | SuaveDandy: You need to make sure you schedule scrubs, so that's a little more effort. |
| 18:09.02 | mason | Without scrubs, you risk things going wrong and not getting caught in time to fix. |
| 18:09.28 | SuaveDandy | And the ZFS guys said noobs shouldn't use such an expert system and should use Ext4 instead. |
| 18:10.05 | SuaveDandy | So I thought. |
| 18:13.36 | fsmithred | 20 years of linux here and still using ext* |
| 18:15.26 | SuaveDandy | I don't know if I should go forward. I mean, will I have enough time to learn ZFS, set up my whole system with window manager and work? |
| 18:15.33 | SuaveDandy | I don't even know. |
| 18:16.05 | SuaveDandy | But I mean, on Windows I always had a long acclimatization period after installing anyway. |
| 18:16.26 | SuaveDandy | And still didn't have the things my way like the keyboard layout. |
| 18:16.50 | SuaveDandy | Or the window layout. Or the popup terminal. |
| 18:16.53 | fsmithred | takes me a few weeks to get a new system all set up |
| 18:17.19 | *** join/#devuan f0rs3ti (~f0rs3ti@pivpn/maintainer/f0rs3ti) |
| 18:19.31 | SuaveDandy | Do you think it's a better idea to learn ZFS in VM or I can learn it on-the-fly? |
| 18:19.58 | fsmithred | I don't know it, so I can't estimate. |
| 18:20.09 | SuaveDandy | mason? |
| 18:20.54 | yanmaani | how can it take weeks to set up a file system |
| 18:20.57 | yanmaani | ext4 takes minutes |
| 18:21.02 | mason | SuaveDandy: I'd use it live. That's how I did it anyway, to learn. |
| 18:21.06 | fsmithred | not to set up a file system |
| 18:21.14 | fsmithred | weeks to get my installation the way I want it |
| 18:21.25 | yanmaani | I've had this crazy idea |
| 18:21.28 | mason | SuaveDandy: The tricky bits are getting comfortable sending/receiving snapshots for incremental backups, etc. |
| 18:21.28 | yanmaani | you make a "DE" |
| 18:21.32 | SuaveDandy | Live as in on a live CD? |
| 18:21.39 | yanmaani | which is just "what normal people want for their system" |
| 18:21.41 | fsmithred | initial install of the OS only takes me 10 minutes from a live iso |
| 18:21.43 | yanmaani | where normal people == you |
| 18:21.49 | fsmithred | yeah, usually DE |
| 18:21.51 | mason | SuaveDandy: And since ext does nothing like that, that's really like learning different tools, unrelated to the files sitting there and being accessed |
| 18:22.07 | yanmaani | so, mpv for media player, FF ESR for browser, that sort of thing. |
| 18:22.32 | SuaveDandy | mason, what do you mean by "live?" |
| 18:23.23 | fsmithred | I think he means "on hardware and in use" |
| 18:23.43 | mason | that |
| 18:23.45 | fsmithred | not a test run |
| 18:24.03 | fsmithred | like getting thrown in the water to learn how to swim |
| 18:25.44 | fsmithred | SuaveDandy, did you try the deboostrap install on zfs? |
| 18:25.59 | SuaveDandy | Not yet. |
| 18:26.08 | SuaveDandy | Was discussing stuff. |
| 18:26.12 | SuaveDandy | Gimme a sec. |
| 18:26.20 | fsmithred | how long did it take to set up the zfs stuff? |
| 18:26.25 | *** join/#devuan IoFran (~Thunderbi@189.237.153.168) |
| 18:26.50 | fsmithred | or better, how long would it take to do it again, now that you know how? |
| 18:31.08 | SuaveDandy | Well, heh. A couple of half an hour. |
| 18:33.38 | *** join/#devuan yeti (~username@p2e517767.dip0.t-ipconnect.de) |
| 18:37.24 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12:47e7:da35:4706:d36c) |
| 18:40.11 | SuaveDandy | I'mma speed up, guys. |
| 18:40.26 | SuaveDandy | Focus mode: on |
| 18:49.38 | *** join/#devuan Kruppt (~Kruppt@50.111.15.137) |
| 18:55.42 | *** join/#devuan user_ (~user@188.27.70.107) |
| 18:55.55 | user_ | Devuan mentioned https://www.theregister.com/2020/09/10/debian_project_address/ |
| 18:56.32 | user_ | chuckles a bit, muahaha, not enough people to perfect total Poetteringization? or not enough people to prevent too much breakage by that prolific man. |
| 18:56.35 | *** join/#devuan HalfWord (~halfword@0-190.dsl.iskon.hr) |
| 18:58.11 | user_ | hehe comments start with a very much #devuan close question >:-) https://forums.theregister.com/forum/all/2020/09/10/debian_project_address/ |
| 18:58.23 | user_ | is done with noise, people can read if they want to. The links. |
| 19:00.47 | user_ | chuckles as usual reading the comments, thereg comments are worth as much as the article(s) imo |
| 19:01.57 | golinux | Please take it to #debianfork |
| 19:02.33 | user_ | np, done |
| 19:42.52 | *** join/#devuan diogenes_ (~diogenes_@188.208.123.74) |
| 20:20.11 | *** join/#devuan fncapkle (~sb35@184.75.215.2) |
| 20:24.48 | *** join/#devuan gnu_srs1 (~srs@host-95-192-100-141.mobileonline.telia.com) |
| 20:29.37 | SuaveDandy | So. We have configs and user data backed up to the cloud. And the whole system backed up to the external drive, say, once in 6 months. The hardware failure is unlikely to happen. Does that mean that ZFS snapshots are redundant? |
| 20:29.44 | SuaveDandy | mason |
| 20:30.07 | SuaveDandy | I'm not going to do anything stupid. |
| 20:31.21 | SuaveDandy | Although I may mess the software up⦠|
| 20:31.28 | SuaveDandy | Makes sense. |
| 20:32.06 | mason | Snapshots are useful as point-in-time references on top of their use in doing incremental back-ups. |
| 20:32.38 | SuaveDandy | Something like restore points? |
| 20:32.59 | mason | Yes. |
| 20:33.21 | SuaveDandy | I just thought that Debian is super reliable. |
| 20:34.17 | gnarface | SuaveDandy: Debian is super reliable. You, however, by comparison, are not. |
| 20:34.27 | SuaveDandy | Heh. |
| 20:34.35 | SuaveDandy | Well, I'm only human. |
| 20:34.42 | gnarface | SuaveDandy: sometimes you only realize you made a mistake months later. that's when it's good to have historical snapshots to refer to |
| 20:35.35 | gnarface | SuaveDandy: we are all only human. well, most of us are. i might not be, but i'm no less error prone for it. |
| 20:36.26 | gordonDrogon | when I was being paid to sysadmin, users deleting files was very common. less common was "can you get that version of the file I had 3 weeks ago", but it did happen. |
| 20:37.54 | gnarface | ransomware attacks and mysql database corruption also come to mind |
| 20:44.16 | specing | I have hourly snapshots and they had saved me dozens of times already |
| 20:44.38 | *** join/#devuan mith_ (~Mithrandi@46.234.217.137) |
| 20:44.51 | specing | and half of those dozens of times were when messing with git |
| 20:45.05 | specing | and nuking my working checkout by accident |
| 20:45.37 | specing | the snapshots are kind of like revision control system control system |
| 20:52.39 | *** join/#devuan IoFran (~Thunderbi@189.237.153.168) |
| 20:59.36 | *** join/#devuan ham5urg (~ham5urg@2a04:4540:6807:4c00:656a:5030:1141:12a3) |
| 21:08.48 | *** join/#devuan gnu_srs2 (~srs@host-95-192-247-83.mobileonline.telia.com) |
| 21:25.52 | *** join/#devuan sammi`_ (~qw@114-40-112-138.dynamic-ip.hinet.net) |
| 21:27.33 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 21:28.06 | *** join/#devuan leafwiz (~leafwiz@2.79-160-198.customer.lyse.net) |
| 21:28.23 | mason | Ooh, I may have identified my startup race. At least, this matches what I see: https://linux.debian.bugs.dist.narkive.com/a99qRmYJ/bug-912237-etc-init-d-rpcbind-stat-not-found |
| 21:30.49 | mason | Looks like I've been bitten by a UsrMerge bug. |
| 21:31.22 | mason | This could be another one for us to fork. |
| 21:31.37 | mason | I'll see if there's a Debian-side bug. |
| 21:31.50 | mason | bbiab, rebooting, testing |
| 21:37.53 | *** join/#devuan leafwiz (~leafwiz@2.79-160-198.customer.lyse.net) |
| 21:40.19 | *** join/#devuan climbingturtle (~climbingt@c83-248-135-84.bredband.comhem.se) |
| 21:43.05 | *** join/#devuan unixbsd (openbsdtai@gateway/shell/ircnow/x-oexdsscokkatxhgr) |
| 21:43.22 | unixbsd | is XFS on devuan more stable than EXT4? |
| 21:48.15 | gnarface | it is more stable period. |
| 21:49.09 | gnarface | but that doesn't mean it will be the best choice in every situation (for example, Valve's Steam client for Linux has had a history of obscure patch failures on anything other than ext4) |
| 21:50.53 | gnarface | also, even though generally everything is faster with XFS, deletions are slower, so there may be very different performance implications depending on the work load |
| 21:51.56 | gnarface | i would just suggest to try it |
| 21:52.58 | gnarface | if you want faster launch times and more read throughput, XFS is a shoe-in unless you only have a single-core system (XFS is also the only multithreaded filesystem) |
| 21:55.42 | gnarface | on the other hand, if you want a build server for kernels, and you do a lot of "rm -rf /usr/src/*" and the like, the delay time might get annoying |
| 21:57.07 | gnarface | not like, cripplingly slow, but if you are used to all deletions being basically instantaneous you might get frustrated having to wait 30s to delete 2GB of small files |
| 21:57.09 | Wonka | Back Then[tm], when I used XFS, after crashes all files that had been open for writing during the crash were completely zeroed. Didn't happen with ext3. (ext4 didn't exist yet) |
| 21:58.23 | gnarface | Wonka: it would put the unfinished file chunks in /lost+found/ and you just had to identify them and you could usually manually put them back in place. i haven't seen it have that problem for several years now. i think they changed default mount options and did some internal tuning. |
| 21:59.22 | gnarface | Wonka: in the mean time, the ext4 team can't even keep slightly outdated versions of e2fsprogs from unraveling the whole filesystem |
| 22:00.04 | Wonka | haven't had problems there, and I'm running -rc kernels for years now |
| 22:00.05 | gnarface | Wonka: (which they quietly sweep under the rug instead of putting a warning label on it like they should) |
| 22:00.53 | *** join/#devuan alexandros_c (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 22:00.57 | gnarface | but then, the primary risk for servers losing power for me is them losing power, so just keep everything on UPS, so ymmv. |
| 22:01.15 | *** join/#devuan alexandros_tab_ (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 22:24.54 | *** join/#devuan SuaveDandy (~androirc@93-81-61-68.broadband.corbina.ru) |
| 22:26.13 | SuaveDandy | mason: Just to clarify. Is it a neat idea to make a dataset for /usr? I heard Bash and other user-executable programs are here. |
| 22:27.39 | SuaveDandy | Just to clarify before debootstrapping. |
| 22:27.56 | gnarface | dataset? |
| 22:28.09 | SuaveDandy | ZFS dataset. |
| 22:28.19 | SuaveDandy | So I can snapshot it seperately. |
| 22:28.39 | mason | SuaveDandy: You're talking about a usrmerged system. Without usrmerge it's in /bin/bash. |
| 22:28.39 | gnarface | user executable programs should be mostly residing in the followind directories: /sbin, /bin, /usr/bin, /usr/sbin |
| 22:29.10 | mason | SuaveDandy: The script I showed you shows the directory structure I prefer, but you have to decide what you want. |
| 22:29.29 | gnarface | (you might have stuff in /usr/local/bin and /usr/local/sbin but if you were following the rules there shouldn't be anything there you didn't put there yourself) |
| 22:30.16 | SuaveDandy | I guess it's simpler to just snapshot the whole root except userdata so I don't have to check which software is where. |
| 22:30.38 | SuaveDandy | Do BSDs still use /usr as /home? |
| 22:30.44 | mason | Recursive snapshots are useful. I would snapshot user data too. User data especially. |
| 22:30.52 | SuaveDandy | Or did they switch to /home too? |
| 22:31.04 | MinceR | OpenBSD uses /home |
| 22:31.05 | mason | NetBSD and OpenBSD use /home. FreeBSD and presumably DragonFly use /usr/home. |
| 22:31.21 | mason | bbiab, dinner |
| 22:32.19 | SuaveDandy | Wanted to try NetBSD also. It is said that it has great compatibility due to abstracting the hardware components. |
| 22:32.32 | SuaveDandy | Very interesting architecture. |
| 22:33.00 | SuaveDandy | Sorta like Project Treble but deeper. |
| 22:37.44 | SuaveDandy | mason: Hey! The ZFS guide does include linux-headers-amd64 and linux-image-amd64 installation after all! |
| 22:37.55 | SuaveDandy | You didn't have to worry. |
| 22:38.21 | SuaveDandy | Perhaps this guide is more robust than it seems. |
| 22:39.11 | SuaveDandy | But wait. Do locales need elogind? |
| 22:44.25 | gnarface | SuaveDandy: locales should not need elogind |
| 22:45.18 | gnarface | at least it didn't last i checked... |
| 22:45.32 | gnarface | things like that have been shifting lately in a bad direction |
| 22:47.28 | yanmaani | why is directory strucutre so bad? |
| 22:47.31 | yanmaani | why doesn't anyone fix it? |
| 22:47.53 | yanmaani | like why are there folders /etc and /usr? why /opt? |
| 22:49.21 | *** join/#devuan phogg (~phogg@static-108-51-94-2.washdc.fios.verizon.net) |
| 22:49.22 | *** join/#devuan phogg (~phogg@pdpc/supporter/student/phogg) |
| 22:51.35 | golinux | yanmaani: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard |
| 22:52.03 | SuaveDandy | Because it's not NixOS/GoboLinux/BSDs. |
| 22:52.47 | gnarface | yanmaani: it makes a lot more sense if you remember computers that were slow enough that character counts in file paths were an actual performance issue |
| 22:52.53 | SuaveDandy | Have problems with the structure? Use these instead. |
| 22:52.56 | gnarface | yanmaani: (and storage issue) |
| 22:53.02 | SuaveDandy | Okay. Gobo's too obscure. |
| 22:53.26 | SuaveDandy | Wait. Wasn't Gobo a Debian fork? |
| 22:53.35 | gnarface | yanmaani: but it is also designed to categorize files by type instead of by package association, because this made distributing read-only parts of the filesystem easier |
| 22:53.38 | SuaveDandy | I remember it was. |
| 22:53.52 | yanmaani | gnarface: they have improved since then as I understand it |
| 22:54.03 | yanmaani | that they had problems back then I don't doubt, but why keep it now? |
| 22:54.38 | gnarface | yanmaani: the computers? yes. but all you have to do is try running some Linux software on OSX (which works after you fix the paths) to realize why nobody who is sane and not being paid does shit like that |
| 22:54.48 | SuaveDandy | Heard BSDs have a better directory structure and are easier to admin in that regard. |
| 22:54.51 | yanmaani | I know there's some distros which change it |
| 22:54.56 | MinceR | probably more of an issue with typing and printing on teletypes with slow connections |
| 22:55.05 | yanmaani | it seems like installing all binaries in /bin is a good first step |
| 22:55.23 | gnarface | yanmaani: there was also meant to be security barriers betweeen / and /usr |
| 22:55.54 | SuaveDandy | NixOS uses containers. That way you can track the deps with hash names and store multiple files so you won't get into a dep hell. |
| 22:56.12 | SuaveDandy | Multiple versions. |
| 22:56.17 | SuaveDandy | Not files, sorry. |
| 22:56.47 | SuaveDandy | By brain coockoogaga when it's night. |
| 22:57.22 | gnarface | yanmaani: sorry, i've been working on trying not to accidentally do injustice to people by hiding the truth by being too polite. the simple version is it's not that complex and if it seems bad to you, your opinion is sophomoric (and the proof of that is that nobody who does understand it wants to change it anymore) |
| 22:57.26 | stovepipe | oh god |
| 22:57.50 | stovepipe | i was going to say, go learn A LOT more about unix |
| 22:58.00 | gnarface | yanmaani: the words seem arcane and esoteric because they're shortened, but contextually it makes a lot of sense |
| 22:58.26 | gnarface | yanmaani: and the barriers they provide to you are only there at first. they evaporate once you understand the context |
| 22:58.57 | stovepipe | and other small details why all binaries are not in /bin |
| 22:58.58 | gnarface | yanmaani: it is important you don't take this personally. they didn't do it to hold it out of your reach. |
| 22:59.38 | stovepipe | +like |
| 22:59.40 | gnarface | yanmaani: (and indeed it is not beyond your reach, in fact it would not even require mustering nearly as much willpower as you fear) |
| 23:00.10 | stovepipe | slight paradigm shift |
| 23:00.15 | stovepipe | state of mind thing |
| 23:00.19 | gnarface | yea |
| 23:00.38 | gnarface | can't be explained easily, but try it and you'll like it |
| 23:00.51 | yanmaani | Try what? Using a filesystem? |
| 23:01.15 | stovepipe | understanding why things like /etc exist at least |
| 23:01.15 | yanmaani | https://sta.li/filesystem/ This seems like a reasonable proposal |
| 23:01.16 | gnarface | yanmaani: no i mean literally try liking the FHS as it is, before you plan on how you're going to replace it |
| 23:01.20 | yanmaani | and I can't think it'd break too much stuff |
| 23:01.38 | yanmaani | I understand it as "historical path dependency reasons" |
| 23:01.43 | yanmaani | which, yeah, I guess. |
| 23:01.49 | stovepipe | "historical" |
| 23:01.50 | gnarface | is sophomoric |
| 23:02.08 | gnarface | true, but scratches only the surface, leaving you devoid of the awareness of reasoning behind it |
| 23:02.10 | stovepipe | i also hear "cryptic" alot |
| 23:02.26 | gnarface | cryptic, or arcane are fair, but again that's just shortened words |
| 23:02.47 | gnarface | <PROTECTED> |
| 23:02.48 | stovepipe | itrs also another initial fear type response to unix shell etc |
| 23:02.57 | yanmaani | But /usr isn't user's stuff, that's in /home |
| 23:03.06 | stovepipe | to brush it off as "cryptic" instead of understanding it |
| 23:03.08 | yanmaani | I've been using the unix shell for a long time now |
| 23:03.18 | stovepipe | userland |
| 23:03.24 | yanmaani | I understand where the stuff is, I just can't understand why there isn't any effort to make it more sensible |
| 23:03.30 | gnarface | yanmaani: ah but here is where you're wrong, but i put the apostrophe in the wrong place; it's "users'" |
| 23:03.33 | stovepipe | it is perfectly sensible |
| 23:03.39 | stovepipe | you just dont understand it |
| 23:04.07 | stovepipe | there is no reason to make everything universal to appeal to the least common denominator, that is making everyone stupid instead of advancing humanity |
| 23:04.21 | gnarface | yanmaani: /home is individual user's stuff. /usr is all the users shared stuff. stuff in /sbin and /bin was meant to be for administrative purposes and booting (back then putting it all on one disk was costly and rare too) |
| 23:05.04 | mason | SuaveDandy: Eh? Not remembering being worried about something. You'll need to refresh my memory. |
| 23:05.05 | yanmaani | But /usr isn't on a separate disk now. Why can't you merge /usr/bin/, /usr/sbin/, /bin/, and /sbin/? |
| 23:05.20 | gnarface | yanmaani: because it would literally cost more than it is worth. |
| 23:05.27 | gnarface | yanmaani: it's not a "can't" it's a "won't, that's stupid" |
| 23:05.31 | stovepipe | yanmaani: filesystems are whever theyre put |
| 23:05.43 | stovepipe | i assume you mean how distros default to a single partition install for end users |
| 23:05.46 | stovepipe | see my above comment |
| 23:06.05 | yanmaani | I have /home on a separate part. Do many people hae separate /usr ? |
| 23:06.18 | gnarface | yanmaani: yea. it's actually strongly recommended for security. |
| 23:06.18 | stovepipe | lots |
| 23:06.27 | stovepipe | the point is to have / on a separate partition |
| 23:06.38 | stovepipe | which ands up with all that other stuff |
| 23:06.40 | gnarface | yanmaani: i'd recommend separate partitions for at least: /home, /usr, /tmp, /var, and / |
| 23:06.42 | stovepipe | and var gets written al ot |
| 23:06.47 | stovepipe | so does /usr |
| 23:06.52 | stovepipe | and /etc |
| 23:07.15 | stovepipe | if anyone tries to take /etc away from me i will hunt them down personally |
| 23:07.46 | stovepipe | i didnt mean /etc needs a separate partition |
| 23:08.25 | stovepipe | just questioning why it exists makes me nervous |
| 23:08.47 | gnarface | yea, that gets back to my advice of "just use it until you like it" |
| 23:08.50 | stovepipe | gives me that binary registry kind of feeling |
| 23:08.57 | stovepipe | PC-BSD was doing that |
| 23:09.17 | stovepipe | mystery undocumented binary registries and processes |
| 23:09.37 | gnarface | yanmaani: for what it's worth, most of what you're complaining about, i remember having the same arguments against it when i was new. literally do what i did, and just stare at it until you like it. |
| 23:10.00 | gnarface | yanmaani: that's the simplest advice i can give you that will lead you to the truth. actually putting it in words would probably take me years. |
| 23:10.19 | gnarface | yanmaani: (similar to the amount of time it would take to change) |
| 23:10.37 | stovepipe | linux on the desktop, any day now! |
| 23:11.10 | stovepipe | i dont think that means what they think it means heh |
| 23:12.04 | stovepipe | linux was my main workstation for decades until i switched it to freebsd in anger |
| 23:12.04 | SuaveDandy | What locale should be the default? Is it C. UTF-8? US? My language? |
| 23:12.27 | stovepipe | then devuan made me hate it less |
| 23:13.01 | gnarface | SuaveDandy: you probably want the right one for whatever language you've set it to, yes, but i would still also include utf8 and iso-8859-1 to keep buggy improperly internationalized stuff from crashing on you unexpectedly |
| 23:14.05 | gnarface | SuaveDandy: (though i haven't seen such stuff in a while here, i also haven't tested extensively so ymmv) |
| 23:14.48 | stovepipe | i wonder if there are secret agents spreading pro-systemd propaganda around IRC |
| 23:15.17 | gnarface | doesn't wonder |
| 23:16.07 | stovepipe | systemd wants to take over the whole filesystem |
| 23:16.17 | SuaveDandy | ru_RU doesn't have ISO-8859-1. It has⦠ISO-8859-5⦠|
| 23:16.26 | stovepipe | no more /home or /usr or /etc |
| 23:16.39 | SuaveDandy | Whatever that is. |
| 23:17.09 | gnarface | SuaveDandy: oh, you're RU? yea, you actually probably want the extended latin character set too |
| 23:17.38 | SuaveDandy | SECRET AGENT: You better use Systemd, dawg. We don't want any casualties. |
| 23:17.43 | gnarface | SuaveDandy: don't omit latin1 though. broken programs that aren't properly internationalized will often fall back to iso-8859-1 instead of C |
| 23:18.12 | gnarface | SuaveDandy: (just don't make latin1 your default - though i'm not sure it even would matter in your case) |
| 23:18.50 | unixbsd | which fs on devuan can support bad blocks? zfs only ? ext2 with newfs_ext2fs -c ? more fs? |
| 23:19.03 | gnarface | SuaveDandy: and if you have to take data from windows systems you might find a use of including the cp1215 and cp1212 or whatever they're called (there's 2-3 windows-specific variations of latin1) |
| 23:19.31 | gnarface | unixbsd: i thought they all did. i guess i'm not sure but at least ext2, ext3 and ext4 for sure |
| 23:19.46 | SuaveDandy | Don't see Latin1. I see only lt_LT. |
| 23:20.09 | gnarface | SuaveDandy: sorry. i'm being lazy and omitting data i thought you already had. "Latin1" == "ISO-8859-1" |
| 23:20.33 | fsmithred | lt Lithuanian |
| 23:20.40 | fsmithred | or Latvian |
| 23:20.51 | SuaveDandy | Is it the en_EN one? |
| 23:21.10 | gnarface | SuaveDandy: i think it's labeled en_US but double check |
| 23:21.20 | SuaveDandy | Oh, sorry. |
| 23:21.24 | fsmithred | yeah, en_US |
| 23:21.24 | SuaveDandy | en_US |
| 23:21.31 | fsmithred | or en_GB |
| 23:21.42 | gnarface | SuaveDandy: https://en.wikipedia.org/wiki/ISO/IEC_8859#The_parts_of_ISO/IEC_8859 |
| 23:21.56 | SuaveDandy | Silly me. Brain coockoogaga. Can barely remember things now. |
| 23:22.12 | unixbsd | xfs, btrfs, jfs, and ufs2/ffs have no bad sector list. Well only ext2 and ext4, with mkfs.ext4 -c /dev/x has a bad sector list. |
| 23:22.16 | SuaveDandy | And say what I didn't mean. |
| 23:22.36 | unixbsd | best is really to use Zfs, but well, there is no choice zfs is the best. however, it uses fuse, which is very unreliable. |
| 23:22.58 | gnarface | unixbsd: yea the zfs integration isn't as good as with bsd |
| 23:24.03 | mason | unixbsd: ZFS doesn't use fuse for the last decade or so. |
| 23:24.12 | gnarface | SuaveDandy: don't forget to add some russian character sets. most the english utf8 ones don't enclude a full set of glyphs, so they won't crash your shit but you'd still probably get empty squares in place of characters |
| 23:24.28 | unixbsd | bit depressing. ... ext4 can check bad sectors but the GPL will make it out of use for servers on bsd, ext4 is maybe more reliable than ufs2. zfs usees all the memory of your system. Open a firefox and use zfs and you will work next day or next month, after waiting hours. |
| 23:24.36 | gnarface | SuaveDandy: sorry *russian fonts* to be clear |
| 23:25.12 | gnarface | unixbsd: try XFS? it's not fancy but it's old and fast :) |
| 23:25.44 | unixbsd | xfs has no bad block check before "format". if you get a bad block your disk is "dead" using xfs. |
| 23:26.39 | SuaveDandy | Should I use ru_RU or ru_RU.UTF-8 as the default? I suppose ru_RU is the ISO-1889-5 one. |
| 23:26.44 | unixbsd | jfs is even worse when a bad block occurs. this I remember one hour at each boot using jfs for one single sector. |
| 23:27.11 | SuaveDandy | Do you guys choose locals too or just install all of them? |
| 23:27.17 | unixbsd | mason: mkfs.zfs ? |
| 23:27.21 | gnarface | SuaveDandy: i choose |
| 23:28.10 | gnarface | SuaveDandy: these days, i would say ru_RU.UTF-8 is probably the better choice, but that's based only on the fact my advice for en_US.UTF-8 changed the same way a couple years ago |
| 23:28.30 | SuaveDandy | Ah. |
| 23:28.32 | SuaveDandy | Okay. |
| 23:28.56 | gnarface | SuaveDandy: with en_US.UTF-8, you can trust that it is 100% a superset of en_US. with ru_RU maybe it is only 99% so i don't know for sure. |
| 23:29.13 | gnarface | SuaveDandy: it should be safe to pick everything you *might* need |
| 23:29.25 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
| 23:34.29 | SuaveDandy | For the future: installing OpenRC right after debootstrapping was a bad idea. |
| 23:35.02 | gnarface | what happened? |
| 23:35.19 | SuaveDandy | DEVUAN: YOU SHOULD REBOOT IMMEDIATELY!! |
| 23:35.25 | unixbsd | i love openrc |
| 23:35.26 | gnarface | hah. oh |
| 23:35.35 | unixbsd | openrc is way better than default devuan rc |
| 23:36.22 | SuaveDandy | Probably that's why the locales failed to install before. |
| 23:37.21 | SuaveDandy | I mean, to set up. |
| 23:37.33 | SuaveDandy | The package itself got installed. |
| 23:37.55 | SuaveDandy | Maybe --include and --exclude did nothing wrong. |
| 23:38.30 | SuaveDandy | I'll try again. After I'll get some sleep. Again. |
| 23:40.22 | unixbsd | how to fix bad sectors on linux ext4 on a disk 4tb with data on it? |
| 23:41.16 | Hurgotron | fsck.ext4 ? |
| 23:41.37 | unixbsd | does it save and remove them onto a blacklist of dead sectors??? |
| 23:43.08 | Hurgotron | well, if the media is not braindead it should relocate the bad sectors on its own... |
| 23:44.28 | Hurgotron | otherweise, well, there's badblocks and you can feed the list to mkfs.ext4 - but that would be destructive |
| 23:44.42 | gnarface | unixbsd: best you read the manpage about fsck.ext4 or badblocks itself (or better yet; both) but i think the idea is something like a linear text file of bad block sector numbers gets generated and you pass it as a mount option |
| 23:45.49 | gnarface | unixbsd: they recommend not running badblocks directly as mkfs.ext4 can call badblocks for you |
| 23:46.45 | gnarface | unixbsd: (note that it does not unless you specifically tell it to though, so read the man page for details) |
| 23:47.05 | gnarface | unixbsd: (and plan 1-2 days in advance. it's gonna take a while) |
| 23:47.57 | gnarface | unixbsd: calling badblocks directly just generates the raw list |
| 23:48.14 | unixbsd | I read on superuser.com that fsck.ext4 -cc /dev/sdb1 ; fsck.ext4 -cc /dev/sdb2 will fix it... read and write. so I tried. let's wait one or two days... |
| 23:49.37 | unixbsd | in comparison, unix has not such a feature.. the bsd ufs has not bad block check. this is a good advantage for end users for daily home usage. |
| 23:49.38 | gnarface | you might have wanted to set it to output some sort of progress meter but yea that should do it |
| 23:49.40 | Hurgotron | looks good, I didn't know that option yet. |
| 23:50.25 | Hurgotron | OTOH, I would probably not trust damaged media like that too much. |
| 23:50.31 | unixbsd | the all trick is here: mkfs.ext4 -c /dev/sdX to create and regularly: mkfs.ext4 -cc /dev/sdX. |
| 23:50.43 | gnarface | unixbsd: in theory the badblocks test is filesystem agnostic, so if there were a way to omit a list of blocks from the ufs filesystem you could still pass the list generated by badblocks assuming you had set the right block size |
| 23:51.15 | unixbsd | I had in the past notebooks over 20 to 30 years with bad blocks. nothing changed, ;) |
| 23:51.58 | unixbsd | fear can explain all what developers believe and how they can react with their software. ;) dump your pc, but well, it still works today. |
| 23:52.09 | gnarface | yea, sometimes once a few bad blocks appear they start growing like fungus. but sometimes they don't, too. |
| 23:52.12 | SuaveDandy | mason: ZFS uses half the RAM. What if I'll have lots of opened programs? |
| 23:52.40 | unixbsd | zfs will screw whole ram indeed. you cannot run it on a ARM board for sure. |
| 23:52.57 | gnarface | hehe, nonetheless i see pine64 people are trying anyway :) |
| 23:53.18 | SuaveDandy | I have 8 gigs. |
| 23:53.18 | Hurgotron | there are tuning options for zfs. On FreeBSD, it ate *all* my RAM before tuning. |
| 23:53.29 | Hurgotron | (and that was 64GB) |
| 23:53.33 | unixbsd | would be faster to run ext4 |
| 23:53.49 | gnarface | yea i hear a lot that you don't really want zfs running on your desktops/laptops; you want it running on the file server they get backed up to |
| 23:54.06 | mason | SuaveDandy: ARC gets out of the way pretty fast. I've run ZFS on 1g systems unproblematically. |
| 23:54.07 | SuaveDandy | Ah⦠|
| 23:54.17 | unixbsd | at the end, we have no single good FS. |
| 23:54.19 | mason | SuaveDandy: You can even run it on an ARM board. |
| 23:54.30 | unixbsd | maybe ntfs is the key of success <- bad joke. |
| 23:54.51 | mason | In ZFS, we have a good general-purpose FS. |
| 23:54.52 | gnarface | ntfs doesn't even work right in wine |
| 23:55.24 | SuaveDandy | Some people legit think that it's good that Windows uses NTFS instead of Ext4. |
| 23:55.45 | gnarface | i think you can actually use ext4 on windows now |
| 23:55.47 | SuaveDandy | Say that "it's more optimized for it" or something. |
| 23:56.09 | SuaveDandy | I have no idea how you can do that. |
| 23:56.29 | SuaveDandy | You can use BtrFS on ReactOS. |
| 23:56.45 | gnarface | there's a 3rd party ext4 driver for windows |
| 23:56.47 | unixbsd | I tried openbsd A6 but it cannot work long with heavy duty. it fails and crash due to lack of inodes. so no file server in that direction. likely freebsd and linux (sure with ext4) might be best approach for bsd/linux families. |
| 23:56.48 | gnarface | i used it once |
| 23:57.18 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 23:57.23 | SuaveDandy | I wonder. Debian is pretty stable. And even then BtrFS is considered unstable on it. |
| 23:57.33 | unixbsd | systemd? no no |
| 23:57.42 | mason | SuaveDandy: BtrFS will get better. Fedora's picking it up, so it'll get a lot of use. |
| 23:57.43 | SuaveDandy | Seems like BtrFS is lighter and doesn't eat that much RAM. |
| 23:58.15 | mason | The problem there is that you have to chase the bleeding edge kernel for BtrFS fixes. ZFS is developed separately, decoupled from the upstream kernel, and this is a huge win. |
| 23:58.18 | unixbsd | btrfs has no bad block check and fix. ... risky, too risky. |
| 23:58.19 | *** join/#devuan Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 23:58.21 | Hurgotron | I prefer to let the others do the testing :) |
| 23:58.42 | mason | When BtrFS becomes reliable it'll be an awfully good thing. |
| 23:59.15 | unixbsd | without bad block, soon or later, defect occurs, or just use raid or similar |
| 23:59.44 | SuaveDandy | Raid Shadow Legends. |