49[00:27:44] <sney> I don't think that's true, as it produces ELF executables. it's just a whole stack of build environment that has specific dependencies
50[00:27:56] <sney> also currently keeping firefox 85 out of sid
51[00:28:56] <sney> anyone learning rust from the beginning will probably be able to noodle around with the versions in buster, too. they just can't compile big new rust projects from upstream that require a new compiler, new cargo, etc
62[00:33:37] <jhutchins> Yeah, but that puts the admins, who want to run stable, proven code up against the devs, who want a whole bunch of under-tested new, unstable packages on a production server.
63[00:34:26] <sney> hopefully it will plateau at some point
64[00:34:30] <jhutchins> It's one of the things about containers. Great for development. Anything that goes wrong within the container is the developer's responsibility.
65[00:34:46] *** Quits: dvs (~hibbard@replaced-ip) (Remote host closed the connection)
69[00:35:36] <jhutchins> sney: Some of the languages have smoothed out pretty well. Then there's PHP, where the coders (Wordpress) want 7.x and the stable commercial distros are still instaling 5.x
74[00:37:20] <jhutchins> Yep. I've known developers who were sensible about stability, and I've had to work with some who went to a meetup this weekend and want to throw out all of the old systems.
75[00:38:02] *** debhelper sets mode: +l 1168
76[00:38:46] <jhutchins> I worked for a company where the admins were in KC, and were pretty solid guys, but the developers were in New York City and had a shiney new strategy every week or so.
82[00:40:11] <jhutchins> The devs thought if they moved to "dev-ops" in the cloud and put them in charge, they could fire all of us uptight admins and save money on salaries.
83[00:41:06] <jhutchins> Some companies are still on the ascending curve of that learning lesson, some have made it work, and others have said "hell no".
133[01:43:19] <oxek> I ended up downloading the binary release of ffsend from replaced-url
134[01:43:42] <oxek> everything seems to work. I know I have to manually keep track of updates to the app.
135[01:44:23] <oxek> I wonder however, what happens if ffsend is accepted into debian repos? Would apt alert me in any way that there's an upgrade available? Or will apt completely ignore ffsend because it simply does not know about its existence on my system?
236[03:27:10] <TBotNik> All: I was on Kubuntu 14.04 LTS, which had "super windows" allowing the nesting on any window within another window. I asked KDE, they said "Not us", so I asked Ubuntu/Canonical , again the answer, "Not us" and they pointed me to Debian. Q: Did this feature originate with the 2014 Debian release. Anyone know this answer?
265[03:51:23] <oxek> and the upgrade process will be described in the release notes. It might be as simple as changing the sources.list lines, but there might be additional steps to take. We won't know until the release notes are released.
314[04:51:48] <ASDX> to upgrade only 'sudo' to the patched 1.9.5-3 package on Debian 10, after running "sudo apt-get update", the upgradeable version is still an old 1.8.xx version). what's the best way to update that to 1.9.5-3? just download the DEB package and install that with "sudo apt-get --only-upgrade install /tmp/sudo_1.9.5-3_deb10_amd64.deb"?
326[05:07:12] <sponix> ASDX: you could just dpkg -i sudo*.deb
327[05:07:50] <sponix> ASDX: but seriously if you have updates and security both active, the 'apt update && apt upgrade" should do the correct sudo update for you anyway
335[05:12:50] <sponix> needing some help with wireguard. I had it working at one point, and have even attempted to mirror that configuration with no success
336[05:13:17] <sponix> following the same documentation as prior also
340[05:15:04] <rue_mohr> how do I work out what window manager is active?
341[05:15:52] <JackFrost> sponix: Don't use the save config option, basically.
342[05:15:55] <sponix> rue_mohr: you can probably grep a process list like ps ax|grep xfwm
343[05:16:02] *** Quits: dez (uid92154@replaced-ip) (Quit: Connection closed for inactivity)
344[05:16:17] <sponix> JackFrost: umm, I need to take that out of my configuration ?
345[05:16:26] <rue_mohr> no *wm
346[05:16:50] <JackFrost> Basically, if you change something via the commandline tools, it writes to the config option. This is a rather strange setting, and IMO best to leave off.
347[05:17:04] <JackFrost> (A lot of places recommend you turn it on, it really just confuses things.)
486[08:38:56] <r0b0> hello, what is the right way to restart networking in debian buster? I need it to re-read configuration from DHCP.. systemctl restart networking leaves me without an IP address
500[08:45:19] <jelly-home> there's no way to run it safely remotely. Running "ifdown eth0; ifup eth0" under screen or tmux would be slightly better than running it directly over ssh
502[08:46:40] <r0b0> jelly-home, yes, I know - that's why I prefered when networking.service was able to do this using one command - that was pretty safe
515[09:04:18] <r0b0> ok, right now I only run it on VMs, so I can always fix things up on the console if things go wrong... but eventually, I will need to do it on physical hosts and I cannot take any chances there :)
546[09:28:34] <ratrace> if restarting networking.service is "less safe" than running ifdown + ifup ... then a bug report should be filed and the service UNIT amended. I am assuming the problem is in systemd trying ExecStart too fast after ExecStop, so a sleep could be injected in the flow.
551[09:36:51] <ratrace> r0b0: well yes, it does ifdown -a
552[09:37:34] <ratrace> I run all server tasks in a tmux session so interrupted networking doesn't crash my session, turning the task I started incomplete and unable to finish properly
553[09:37:56] <ratrace> or are you saying you _are_ running in tmux or screen and your nics go down and never go back up?
554[09:38:10] <r0b0> ratrace, yes
555[09:38:18] <r0b0> no
556[09:38:20] <r0b0> sorry
557[09:38:44] <r0b0> ssh to the machine and run systemctl directly
558[09:38:53] <ratrace> right, so use tmux or screen next time. also, check the logs. if there _is_ a problem with NICs not coming back at all, it'll surely be logged
559[09:39:14] <ratrace> r0b0: don't do that :) always use tmux or screen. always. interrupted shell will corrupt the tasks you started.
560[09:39:43] <ratrace> network could be interrupted by many things, connectivity issues, packet loss between you and the server, your ISPs DSL router restarting right there and then, etc...
561[09:40:01] <r0b0> I thought that systemctl is just a "client" to systemd and all those ifdown commands are executed outside my current session
562[09:40:49] <r0b0> that's why I thought that it might be quite safe
563[09:40:52] <ratrace> I'm not sure how exactly systemctl and PID1 interact
564[09:41:07] <ratrace> but always check the logs. can you pastebin those?
570[09:47:24] <r0b0> yes' that's it.. kernel reboot after a couple of minutes when I gave up and rebooted the machine on the console
571[09:48:01] <ratrace> try restarting networking.service from a tmux or screen session.
572[09:48:53] <ratrace> when you strace systemctl you can see it attaches to pid1 and the trace goes on into the (re)started service. So I'm convinced that network stopping drops systemctl which interrupts the flow
605[10:00:37] <jelly> ah, didn't notice they rebooted
606[10:01:33] <ratrace> networking.service is a regular part of debian. if it doens't work properly, that's a bug. now of course, use cases vary, but in my case, I've never had issues with it. the part where I did have issues with restarting networking service on debian even before systemd, was timing of start after stop, esp. when dhcp is involved.
607[10:02:36] <ratrace> (or to rephrase better (my coooffffeeee is still brewing) I don't have issues with networking.service, I had issues with /etc/init.d/networking)
608[10:02:55] <jelly> nod
609[10:03:01] <ratrace> which isn't surprising. systemd just runs ExecStop and ExecStart. the init shellscript is all kinds of mess
610[10:04:06] <ratrace> too bad they quit. I'd ask them to inject a sleep in the unit's ExecStart and perhaps confirm this timing theory.
611[10:04:26] *** Quits: szorfein (~daggoth@replaced-ip) (Remote host closed the connection)
691[11:33:11] <desuwulf> mmm, so I found a very old box of mine that has 6 sata drives that used to run an mdadm raid6... 10 years ago until it died. I managed to fix it(cpu&mobo swap needed), but now of course the array isn't coming offline. Backed up with dd/sgdisk/parted the partition data for now but it seems a bit devoid of anything. mdadm --assemble -v complains of "no RAID superblock" for any of those devices(funny enough, the RAID1 os
692[11:33:12] <desuwulf> drives assemble and run fine). mdadm.conf still has the uuid based raid id, but doesn't find anything in scan so it doesn't assemble.
693[11:33:27] <desuwulf> The slight weirdness is iirc this was both GPT disk + full disk mdadm
694[11:33:36] <desuwulf> but I can't exactly remember... thoughts on how could I dry-run this?
778[13:00:04] <azeem> so you want something like strace | grep fanotify, but system-wide and it should tell you when a process runs the fanotify system call?
940[15:04:24] <ZeroWalker> what affect does the clock-setup/utc have, is there some pros con for it? as far as i recall it messes up time with windows cause it doesn't use utc per default, so dual booting causes timezone desync, what i don't really get is how that happens when it's supposed to sync to a time server on either os
949[15:07:14] <ratrace> it's not about time sync (which windows has had for... ever?), it's about windows tendencies to store localtime in the rtc. but windows now (win10 and I don't know how back in releases) has the ability to store UTC time, removing the problme
951[15:07:40] <ratrace> altrenatively, time on the linux side could be set in localtime too, instead of default UTC, to cater to windows, but that's no longer needed, as windows can track UTC
1017[16:01:24] <RadoS> I have 2 NB with wireless adapters, 1 with iwl, the other with ipw. Via udev I wanted to rename them based on 'KERNEL=="wlan*"', but this applies only to iwl, not ipw, why isn't ipw also caught by "wlan*" but is by "eth*" like LAN NICs?
1052[16:21:09] <greycat> I don't know much about your hardware or its drivers and firmware, but the udev method of interface naming is deprecated in buster, and not guaranteed to work. The systemd "dot link" method is what you're supposed to use now.
1053[16:21:39] <greycat> man 5 systemd.link or see various internet documentation
1054[16:22:49] <RadoS> greycat, thanks for pointer, reading.
1056[16:22:56] <dob1> in a script I have command1 & --new line -- command2 & --new line -- command3 & -- new line-- but I still see the outout of the commands on console
1057[16:23:08] <dob1> *output
1058[16:23:10] <greycat> Well yeah, you didn't redirect the output.
1059[16:23:48] <dob1> comand1 & > /dev/null ?
1060[16:23:55] <greycat> redirection has to be before the &
1077[16:28:34] <greycat> when bash was originally being developed, csh was still very popular, so to help people transition away from it, bash adopted a lot of csh crap
1078[16:28:41] <jelly> bifunc2, your machine may gain access to a network, that's a huge attack surface right there
1080[16:29:04] <greycat> csh does not have the ability to redirect stderr in isolation; it can only redirect stdout alone, or stdout and stderr together.
1081[16:29:23] <greycat> the &> redirection operator from csh is how it does the latter, and bash adopted it, but it's still crap
1082[16:29:49] <greycat> or maybe it was >& in csh, who knows, who cares, bash adopted both, and they're both crap
1089[16:31:31] <jelly> bifunc2, if you're installing for the first time on this laptop you might as well use the installer images that already contain the firmware,
1090[16:31:34] <jelly> !firmware images
1091[16:31:34] <dpkg> There are <live> system and <netinst> and DVD images containing non-free Debian <firmware> packages available from replaced-url
1092[16:34:23] <bifunc2> jelly, in practice would you say these non-free softwares are trustworthy?
1093[16:34:33] <jelly> that way you can have network access during installation
1095[16:35:42] <jelly> bifunc2, the firmware comes from the same vendor that made the hardware (eg. the wifi card in your laptop). It's not any more or any less trustworthy than the hardware.
1096[16:35:44] <greycat> sadly if you want wireless, you pretty much *have* to use some non-free firmware at the bare minimum
1097[16:35:58] <jelly> unless specific atheros chips
1098[16:37:00] <jelly> bitblit, do you trust Dell and its choice of hardware?
1099[16:37:19] <jelly> bifunc2, do you trust Dell and its choice of hardware components?
1100[16:37:25] <bifunc2> not really lol
1101[16:37:37] <jelly> then why the hell did you get a dell laptop
1142[16:48:47] <dpkg> Some packages intended for Bullseye (Debian 11) but recompiled for use with Buster (Debian 10) can be found in the buster-backports repository. See replaced-url
1145[16:49:26] <dpkg> Vi IMproved (vim) is an enhanced <vi> editor. Extremely popular clone with syntax highlighting and graphical X interface available. The vim-tiny package no longer installs vim <alternatives> as of version 2:7.2.049-1 (Debian bug #529977). See also <vim refcard>, <cream>, <colored pager>, <vim syntax highlighting>. replaced-url
1146[16:49:36] <tytan> !wireguard
1147[16:49:36] <dpkg> wireguard is probably an in-kernel layer 3 VPN with a reputation for speed and code simplicity. See replaced-url
1148[16:49:46] <greycat> you can also /msg the bot to get private answers
1173[17:05:32] <bifunc2> greycat so all the closed-source firmware installed in debian will, in the end, (since it's firmware) but running one layer below the linux kernel?
1174[17:05:36] <bifunc2> i.e. below software layer
1175[17:05:50] <bifunc2> s/but/be
1176[17:05:54] <greycat> it runs on a computer that's inside a piece of hardware such as a network interface
1233[18:05:34] <sney> also if you update to the 5.9 kernel in backports, you can use the mainline exfat driver, so you don't need to deal with fuse shenanigans, though I doubt that's what's causing the failure here
1235[18:07:28] <vanfanel64> sney, please see my paste, I ma using a .mount to do the mounting. I'm am fairly new to systemd and udev/udisks so I might not be doing this right
1243[18:09:56] <sney> anything like this will require some trial and error, but using the right kind of systemd unit should get you more in the right direction I think.
1244[18:12:15] <vanfanel64> sney, so I should scrap /etc/systemd/system/data-sdcard-mount.service and write a /etc/systemd/system/data-sdcard.mount instead? And what of my udev rule, should just have the SYMLINK+="datavol" part (which is more of a convience thing that is not needed, as I'm using UUID="3537-3761" in /etc/fstab) and what about the ENV{UDISKS_IGNORE}="1" part?
1252[18:15:15] <sney> ok first, as you can see from that freedesktop document, .mount files and fstab entries are used the same way by systemd. so pick one or the other. for something like this with a lot of options, the .mount file will be easier to parse/troubleshoot.
1255[18:16:19] <sney> second, I don't see why you need to symlink the device node, unless that's required for making udisks ignore this device, it sounds like an extra piece that doesn't need to be there
1256[18:16:58] <vanfanel64> sney, just to be clear, what I want to do is prevent this particular card from mounting under /media/$USERNAME/whatever and mont it under /data instead, while any other card would mount normally as the former
1257[18:17:20] <sney> and .mount files need to be named with the path of the mount so if this is going under /data, it would just be data.mount
1258[18:18:04] <vanfanel64> sney, yes, the /dev/datavol is what I originally was going to use for the fstab entry but change it to UUID there so I don't really need /dev/datavol, I just thought I could leave that to make it easier to find the device if I ever needed to.
1259[18:18:36] <vanfanel64> sney, oh I didn't know it had to match, I thought it could be any filename.mount
1260[18:19:16] <sney> click on that freedesktop link and read it, it can explain this better than I can
1261[18:20:34] <vanfanel64> yes I have it open, thank you
1262[18:21:19] <sney> and it may help to think of this as 2 separate tasks: 1) make udisks ignore this specific card, so the DE never tries to automount it and 2) mount the card automatically in a set location
1263[18:21:28] <sney> flipping between these two and combining them will only confuse the issue.
1265[18:22:48] <vanfanel64> sney, yes this is what I want to do but I am quite fuzzy on how to properly make udisks ignore it, should I be using my ACTION=="add" rule with just ENV{UDISKS_IGNORE}="1" ?
1268[18:24:37] <sney> that's uncharted territory for me too. just try stuff. #systemd may have ideas as well, or you might find the solution here: replaced-url
1296[18:43:54] <jelly> it's possible a newer version of gparted might work better
1297[18:44:05] <jelly> but you'd have to build it yourself
1298[18:44:08] <sney> that's some version jump
1299[18:44:40] <serard> Hello. I have set my apt-cache-ng VM, I set another VM, it works but... slow..
1300[18:44:40] *** Quits: TomyWork (~TomyLobo@replaced-ip) (Remote host closed the connection)
1301[18:44:49] *** Quits: chele (~chele@replaced-ip) (Remote host closed the connection)
1302[18:44:50] <serard> the other VM use the first apt-cache-ng as proxy
1303[18:45:49] <Sarcutus> jelly: Having problems installing gparted.
1304[18:47:19] <sney> Sarcutus: sounds like you ignored [10:44:04] <jelly> but you'd have to build it yourself
1305[18:47:35] <sney> if you're trying to slap the bullseye package right into buster then yes, you will have "problems"
1306[18:48:04] <Sarcutus> Okay
1307[18:48:27] <jelly> Sarcutus, or perhaps it's just buggy. See if manually loading the "btrfs" kernel module and restarting gparted makes any difference
1313[18:50:35] <dpkg> #debian-next is the channel for testing/unstable support on the OFTC network (irc.oftc.net), *not* on freenode. If you get "Cannot join #debian-next (Channel is invite only)." it means you did not read it's on irc.oftc.net. See also replaced-url
1314[18:51:21] <jelly> you're missing from that channel Sarcutus, and sney is there already
1316[18:51:32] <micros> Does anyone know of a service that can check a processes main thread liveliness (verify its not long term blocked)? I checked some suggestions from earlier but they arent quite the right thing. Like a heartbeat request/response, or a way to do this through the proc file system; or other method. Possibly, make a case why its not needed?
1317[18:53:15] *** Quits: conta (Thunderbir@replaced-ip) (Quit: conta)
1346[19:11:18] <f-a> I would like to monitor my interner traffic, to see which program sends/receive the most
1347[19:11:21] <f-a> what can I use?
1348[19:11:52] <\\Mr_C\\> just mei_wdt xxxxxxxxxxbunch of numbers herexxxxxxxxxxxxxxxxxx: Could not reg notif event ret=-22
1349[19:12:50] <sney> \\Mr_C\\: yep, kernel watchdog stuff, probably some bios/efi funk. if your system works normally otherwise, consider yourself warned and don't worry about it. otherwise, see if your computer mfg has an update
1371[19:24:02] <greycat> Not really. A package has postinstall and other scripts that run as root and can do everything.
1372[19:24:48] *** Quits: conta (Thunderbir@replaced-ip) (Client Quit)
1373[19:25:27] <igrtrrt> Hi everybody, I'm trying to run the latest kernel LTX(5.10) compiled by myself, but I'm having a problem decrypting my LUKS partition after the boot
1374[19:25:35] <igrtrrt> This is the only kernel that does not accept my password :/
1375[19:25:58] <igrtrrt> 'm following the kernel newbies tutorial(kernelnewbies.org/OutreachyfirstpatchSetup), but I have no idea what is possibly going wrong.
1376[19:26:06] <igrtrrt> I'm*
1377[19:26:13] <igrtrrt> Does Debian have anything special to setup the keyboard or the cryptsetup?
1378[19:29:02] <ratrace> the console-setup package
1379[19:29:19] <ratrace> how are you building and installing the kernel?
1384[19:30:59] <igrtrrt> after copying the .conf from /boot and compile the kernel+modules I send the cmd 'sudo make modules_install install' to install both
1388[19:31:32] <ratrace> which kernel did you copy config from?
1389[19:31:40] *** Quits: tuxmania (~tuxmania@replaced-ip) (Remote host closed the connection)
1390[19:31:55] *** Quits: short-bike (~short-bik@replaced-ip) (Quit: and on that note...)
1391[19:32:00] <igrtrrt> config-4.19.0-14-amd64
1392[19:32:14] <kline[FNODE]> is there an approximate release date for bullseye?
1393[19:32:21] <sney> !wir
1394[19:32:21] <dpkg> well, wir is When It's Ready. See also <rsn> and <siyh>.
1395[19:32:37] <kline[FNODE]> do we know approximately when itll be ready?
1396[19:32:44] <sney> going by the past 2 releases, *probably* Q3 2021
1397[19:32:49] <ratrace> the simplest way is to unpack the tarball from kernel.org upstream somwehre, then copy the config from /boot; then run make oldconfig to set up and configure options for 5.10, then make [-j `nproc`]; then you can either do what you did to install into /boot directly, or you can use make bindeb-pkg
1398[19:32:50] <igrtrrt> > you missed the make oldconfig step? No, I just don't mentioned
1399[19:33:01] <bifunc2> Hey guys, it seems it's possible to replace a Dell XPS 15 wifi card: replaced-url
1400[19:33:02] <bifunc2> He's putting an Intel 9260NGW wifi card in there. On the Intel site, they say "Linux drivers are part of the upstream Linux* kernel." (replaced-url
1401[19:33:03] <bifunc2> Does this mean that this WiFi card will "just work" with the *official* (free software only) Debian 10?
1403[19:33:29] <ratrace> igrtrrt: and naturally you re-ran update-initramfs and update grub?
1404[19:33:42] <kline[FNODE]> sney: thanks. a new machine has arrived so i guess ill have to install from buster media and then dist-upgrade it to bullseye
1405[19:33:48] <ratrace> igrtrrt: (before reboot)
1406[19:33:54] <kline[FNODE]> unless preview media is available already
1407[19:34:03] <sney> bifunc2: iwlwifi supports most intel wireless cards, though it does require firmware in most cases. the issue with replacing laptop wifi cards is usually that the laptop bios is locked to only accept a few specific models
1408[19:34:14] <igrtrrt> The update-grub happens automatically with the make modules_install install
1411[19:34:30] <sney> kline[FNODE]: yes, the testing installer is available at debian.org/devel/debian-installer, the alpha3 works well IME but sometimes it can be iffy
1416[19:35:12] <ratrace> igrtrrt: you need to build the new 5.10 initramfs before grub config, so grub can pick it up for the menu entry
1417[19:35:12] <sney> np
1418[19:35:26] <igrtrrt> ratrace: The update-initramfs I tried afterwards but continue not working(accepting my password)
1419[19:35:42] <ratrace> igrtrrt: you need to re-run update grub after 5.10's initramfs is built
1420[19:35:54] <bifunc2> sney, iwlwifi is not firmware too?
1421[19:36:04] <igrtrrt> Ok, I will try here, thanks
1422[19:36:07] <ratrace> igrtrrt: anyway ... first thing I'd suspect is keymap. without properly built initramfs, the keymap is not set up
1423[19:36:26] <sney> doesn't the kernel include a 'deb-pkg' target to generate a debian package and do all of the initramfs/grub stuff automatically on postinst?
1431[19:37:54] <sney> bifunc2: iwlwifi is the kernel module, free software. but iwlwifi requires firmware, which are non-free closed binary files from intel. you specified "free software only" so I figured you were familiar with this distinction
1433[19:38:56] <sney> ratrace: it's been a minute since I last built a kernel, but maybe the difference between bindeb-pkg and deb-pkg is the inclusion of a linux-headers package and dkms compatibility?
1434[19:38:59] <queip> Video card support was always a mess
1436[19:39:35] <ratrace> sney: no, bindeb builds the actual kernel packages only, deb-pkg builds the src pkg too and needs extra build deps
1437[19:39:36] <queip> how to check which method am I actually using now (like, pure open source, or non-free debian.org repository with less open drivers, or something else)
1438[19:39:51] <queip> for radeon. and how to check for nvidia
1457[19:43:26] <queip> Kernel driver in use: amdgpu Kernel modules: amdgpu
1458[19:43:41] <bifunc2> sney, i just learned about the clear software/firmware distinction today. but how clear is the distinction?
1459[19:43:42] <bifunc2> Here is a concrete question: Is installing closed-source firmware on my laptop just as secure/insecure as purchasing wifi extender + usb<->ethernet adapter + ethernet cable (none of which require closed-source firmware)?
1460[19:43:43] <bifunc2> The latter shifts closed-source firmware to external device (wifi extender). Is this worth it? My fear is basically, having closed-source firmware inside my computer feels more dangerous than having it outside my computer. My computer has all my data, after all.
1461[19:43:43] <bifunc2> Are these fears unfounded?
1462[19:43:58] <ratrace> I don't think if follows with 100% certainty that loaded kernel modules mean Xorg will use them too
1463[19:44:14] <ratrace> to check what Xorg is actually using, is the glxinfo bit above, or look at Xorg.0.log
1464[19:44:24] <bifunc2> s/require closed-source firmware/require closed-source firmware on my computer
1468[19:45:05] <bifunc2> ratrace, sorry, i meant "clear distinction"
1469[19:45:53] <ratrace> meanwhile ... most firmware is closed or licensed non-libre. I wouldn't worry about that. If that bothers you, you should also pry out the IME chip but then you'll brick your computer :)
1506[19:52:32] <ratrace> you'd have to be helluva kernel and GPU microarchitecture expert, in order to "verify" that code. it's not like they're readily available for code audit on a request
1564[20:33:15] <Lope> or does perhaps btrfs or whatever fancy fs have a readonly mode?
1565[20:34:07] <Lope> basically I want a filesystem where I must intentionally write the rootfs state to disk, otherwise it's read-only and won't be corrupted by power failures
1567[20:37:37] <n4dir> skep: if that was a question you can do stuff like chroot. Here are some info, but when i did such years ago there were better how-to's replaced-url
1599[21:10:10] <Lope> I've automated my installs in their face. The only thing that's a wildcard still is I'm currently not telling the kernel to make eth's named eth0 eth1 etc. So ethernet adapter names is something I can't really make "just work" it going to require manual configuration.
1600[21:10:53] <Lope> Even if I did have a predictable ethernet interface name, I would have the problem of NetworkManager things using UUID's etc and I've got no clue how that works.
1601[21:13:00] *** Quits: Mister00X (~quassel@replaced-ip) (Quit: "I'll be back" — Arnold Schwarzenegger)
1628[21:46:14] <ratrace> Lope: why tho. just net.ifnames=0 in grub's config, and use networkd or ifupdown.... why networkmanager, that's.... just..... ereplaced-url
1654[22:01:55] <ratrace> Lope: tried systemd-networkd? it's dead easy to set up
1655[22:01:58] <Lope> But I dislike the fiddlyness of NetworkManager
1656[22:02:00] <sney> n-m is smarter about hotplugging, if you don't always have the ethernet cable connected, or do a lot of suspend/wakeup
1657[22:02:33] <Lope> ratrace, I haven't tried systemd-networkd, I imagine it's more reliable than /etc/network/interfaces?
1658[22:02:57] <ratrace> it's a native systemd tool
1659[22:03:14] <ratrace> I use it on all the servers
1660[22:03:22] <Lope> I've got a bunch of virtual bridges setup with /etc/network/interfaces... if I configure my bridge that my physical NIC is on with systemd-networkd can I still have my other bridges with /etc/network/interfaces ?
1661[22:03:42] <ratrace> but that's static network config, some with bridges, and the nics don't go up or down except on reboots
1662[22:03:52] <Lope> ratrace, does net.ifnames=0 apply in initramfs?
1663[22:04:02] <ratrace> it's a kernel command line option
1664[22:04:04] <jhutchins> Lope: Let's see, NM has been around for maybe five years. interfaces has been around for ~30.
1665[22:04:13] <ratrace> Lope: so you set it via /etc/default/grub
1666[22:04:13] <Lope> ratrace, if I do net.ifnames=0 can I still use udev to rename an interface based on it's MAC?
1678[22:06:16] <jhutchins> Lope: interfaces is proven and reliable and well debuged. NM is pretty new. The first shot at better mobility was Wicd, but these days NM works a lot better.
1679[22:06:26] <Lope> ratrace, yes, I'm aware that net.ifnames=0 is set with grub. Just wondering if it takes effect in initramfs? I'm not quite clear on how much "soft rebooting" happens after initramfs hands over to the rootfs?
1684[22:07:13] <sney> this seems to be the first time it migrated to testing, if 2009 is "pretty new" then I want your time travel secrets, jhutchins replaced-url
1685[22:07:24] <ratrace> Lope: it takes effect whenever udev looks at it for device renaming... so initramfs I suppose due to /dev being needed there and udev doing its work
1687[22:07:50] <Lope> greycat, I've never used net.ifnames=0 but I've used network interface renaming in jessie buster stretch, bullseye etc without issues.
1688[22:08:24] <ratrace> "interfaces", which is to say the ifupdown framework, should be pretty sturdy and debugged by now. but I prefer systemd-networkd because it's better documented and less arcane with configs and also native
1689[22:08:55] <ratrace> Lope: mind you, you can rename interfaces even without net.ifnames=0; with networkd that's based on device Match, which could be MAC based.
1690[22:09:36] <Lope> ratrace, interesting, do you think if I put udev in my initramfs I can rename the ifaces in there?
1691[22:09:44] <Lope> just curious about that
1692[22:09:53] <Lope> Because if I've got multiple nics then isn't net.ifnames=0 a race?
1694[22:10:47] <ratrace> Lope: well there's that possibility of bios flakking things up and eth0 and eth1 and eth2 kinda swap places. that's why binding names to MACs is recommended.
1696[22:11:19] <CrystalMath> now people are attacking /etc/network/interfaces?
1697[22:11:30] <ratrace> you can't even rely on systemd's "predictable" naming as that's anything BUT predictable. MAC binding is the best you can do. Predictable, stable, unless MAC changes but then again.... a meteor could strike your machine too....
1698[22:11:31] <CrystalMath> well no matter, i'll soon be out of this hell thanks to my new slackware install
1699[22:11:43] <CrystalMath> then debian cannot hurt me and my 1993 lifestyle anymore
1702[22:12:53] <Lope> ratrace, naming interfaces by mac, that basically means you rename the network interface, which is something I've always done on all my machines.
1703[22:12:59] <ratrace> slackware is so posh. real haxx0rs run them BSDs. OpenBSD, preferably, that's where the most hate for computing resides.
1710[22:13:23] <CrystalMath> old computing is great
1711[22:13:38] <ratrace> CrystalMath: yes. they hate VMs, too insecure. they hate jails, insecure. namespaces, insecure. MAC frameworks, too much work.
1712[22:13:58] <ratrace> recently they hate SMT and .... soon they'll start hating SMP and go back to single core computing.
1713[22:14:09] <ratrace> and then the hate for x86 will be too much and they'll all transcend to devnull.
1714[22:14:26] <CrystalMath> SMT?
1715[22:14:30] <Lope> They can just buy risc-v
1716[22:14:53] <ratrace> Lope: you just set net.ifnames=0 on the grub command line. that results with renames in initramfs. I'm sure of it because all my servers need dropbear wtih networking inside initramfs
1727[22:15:44] <Lope> ratrace, cool. I thought so. It seems like net.ifnames=0 is cool if you have 1 NIC, but if you have multiple NICs it seems like a bad idea.
1728[22:15:46] <ratrace> SMT is platform agnostic name for that.
1729[22:15:53] <CrystalMath> ratrace: honestly one day i'm just gonna buy a 486 PC and use that
1730[22:16:00] <ratrace> Lope: then you bind the name with MAC addr
1731[22:16:07] <CrystalMath> because i'll just finally think to myself... why not LIVE the dream
1732[22:16:18] <Lope> ratrace, if you're going to rename a network interface, why bother with net.ifnames=0 ?
1733[22:16:24] <ratrace> CrystalMath: that's too posh as well. 386 is before them fancy opcodes that started with 486
1749[22:19:27] <Lope> ratrace, I've arrived at a solution. I'll setup /etc/network/interfaces initially for installs. And if it becomes problematic I'll switch the bridge with the physical NIC to NetworkManager.
1750[22:19:38] <Lope> That way my new installs will "work"
1751[22:20:02] <Lope> Better than a new install without network access
1752[22:20:14] *** BrianG61UK_ is now known as BrianG61UK
1753[22:20:19] <greycat> Atari ST used the 68000
1754[22:20:26] <ratrace> if I were you, I'd investigate why ifupdown has trouble with them bridges. that's not.... normal at all.
1755[22:20:30] <greycat> The Atari 8-bit line used the 6502.
1756[22:20:35] <Lope> my problems with /etc/network/interfaces are likely RealCrap related.
1757[22:20:57] <Lope> generally all my network woes have been Realtek related.
1759[22:21:25] <Lope> but I've come across some workarounds that should in theory make Realcrap more stable/reliable.
1760[22:21:33] <ratrace> btw how did you try setting up a bridge with interfaces? the "old", deprecated way is with brctl iirc. the "new" (for some years now) is iproute based
1761[22:21:44] <CrystalMath> ratrace: but on a more serious note i'm gonna go to slackware and later in life maybe NetBSD :)
1762[22:21:52] <CrystalMath> or maybe dual boot slackware and NetBSD, why not
1763[22:22:11] <CrystalMath> i'm more for living in 1993 specifically
1764[22:22:18] <ratrace> NetBSD is still better than computing-hating knee-jerk-I-got-kicked-out-of-netbsd-so-i-forked-openbsd openbsd.
1765[22:22:32] <CrystalMath> yeah i know, there's a lot of GPL hate there too
1766[22:22:35] <CrystalMath> which is sad
1767[22:22:38] <Lope> ratrace, interesting. I always use brctl when doing manual shenanigans. but 99.9999% of the time my bridges are defined with /etc/network/interfaces for servers and NetworkManager for laptops and Desktops that have Realcrap NICs
1768[22:23:33] <ratrace> my realcrap nics does bridges just fine with interfaces. firmware loaded. r8169 tho. iirc you ahd some abomination that required out of tree DKMs?
1769[22:23:46] <Lope> Whereas NetworkManager seems to be more of a bullshit compatible software.
1770[22:24:47] <Lope> I accidentally overwrote what I typed. I was saying that interfaces seems to say "aah, realcrap, fuck this, I tried a few times, good night"
1771[22:25:06] <ratrace> it's dbus friendly tho. reason RedHat adores it and NM is now de-facto way to manage networks on RHEL servers
1772[22:25:32] <jhutchins> NM on servers. That's nuts.
1773[22:25:42] <ratrace> heh yeah
1774[22:25:47] <Lope> haha I've got one Ryzen 3600 with a Realcrap that won't work at all with r8169, needs 8168dkms to work at all.
1776[22:25:59] <jhutchins> That's like dhcp for servers.
1777[22:26:41] <Lope> I wouldn't be afraid of NetworkManager for servers. In my experience it's extremely reliable.
1778[22:26:41] <ratrace> worse, like avahi-based network setup for servers...... speaking of.... digital ocean sets up the droplets using avahi. NoJoke. TrueStory. almost had a heart attack when I saw that.
1798[22:34:07] <Lope> I tried to install XP on a pentium 133 once. I couldn't believe that I ever used to use one as a daily driver. Let alone a 486.
1799[22:34:16] <CrystalMath> i mean i don't need stuff like acceleration
1800[22:34:19] <CrystalMath> it doesn't work anyway
1801[22:34:28] <Lope> We're talking, a good 15+ years ago.
1802[22:34:31] <CrystalMath> XP is super heavy
1803[22:34:44] <CrystalMath> 15+ years ago i had a Pentium III
1804[22:34:48] <CrystalMath> with like 800 MHz
1805[22:34:55] <Lope> I also had a 1ghz kind of thing.
1806[22:35:01] <CrystalMath> well actually, it was a Pentium III equivalent
1807[22:35:06] <Lope> Athlon and Duron
1808[22:35:06] <CrystalMath> AMD K6 i think
1809[22:35:15] <CrystalMath> it wasn't Intel
1810[22:36:17] <Lope> But I thought the Pentium would be cool as a second computer. I actually tried a beowulf for fun. But they were so unusably slow. Booting windows took forever. Then just playing an mp3 was barely doable and basically used almost the whole CPU hahahaha.
1828[22:38:00] <CrystalMath> i just realized that disk has been running for like
1829[22:38:01] *** debhelper sets mode: +l 1200
1830[22:38:03] <CrystalMath> 15 years straight
1831[22:38:09] <Lope> When modems were a thing and NAT was like an ultra cool hack. and almost NOBODY on earth had a ROUTER.
1832[22:38:12] <phogg> Performance XP on a 133MHz isn't much different from Win10 on low end boxen today, if you take in to account how much background garbage is running.
1833[22:38:19] <CrystalMath> and yeah it has some issues but it still works ?_?
1834[22:38:34] <CrystalMath> phogg: it can probably be tuned really
1835[22:38:42] <CrystalMath> you can get rid of a lot of XP stuff
1836[22:38:55] <Lope> phogg, tru dat.
1837[22:39:21] <Lope> It amazes me how deep windows users will take it.
1840[22:39:51] <phogg> In ~2000 I set up a Linux box with pppd dial-on-network-activity + NAT for the LAN and my family stopped fighting over who got to use the internet.
1841[22:39:53] <Lope> They need a 5ghz CPU to feel like their PC is responsive.
1842[22:40:08] *** Quits: JohnML (~john1@replaced-ip) (Remote host closed the connection)
1844[22:41:23] <Lope> I got a redhat CD and installed linux before the year 2000. But unfortunately I had no idea what to do with linux or how it worked etc. I just typed ls and cd etc. startx etc but that was all I really figured out.
1845[22:41:43] <Lope> I had no access to community or documentation that I was aware of etc.
1846[22:41:50] <CrystalMath> phogg: those were the good old days :)
1847[22:42:09] <Lope> Then that hard drive crashed. One of the biggest mistakes of my life was not learning Linux back then.
1848[22:42:11] <CrystalMath> gosh, what i wouldn't give to be young again
1849[22:42:26] <Lope> I wasted like 15~20 years on windows.
1859[22:45:13] <Lope> "I know how to click stuff and change a few registry keys! hooray for me. I can control the windows noob OS so that it's slightly customized! I changed settings bro! And a few hidden settings! 1337!
1860[22:46:14] <Lope> Speaking of read only, did you ever try XP with EWF? Enhanced write filter. I thought I was so 1337 with that.
1861[22:46:47] <phogg> I don't know what that is. The farthest I got in customization was shell replacement and theming.
1862[22:47:38] <phogg> I tried all of the alternate shells, but mostly used LiteStep. In some ways AfterStep was a downgrade from that. It was certainly more work.
1916[23:37:39] <ASDX> ahh great. i was stupidly going off replaced-url
1917[23:40:12] <sney> backporting security patches to the stable package version is one of debian's standard procedures, when comparing versions make sure to look at the extra strings like '-1+deb10u3', they're not just a decoration :)