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 :)