1[00:00:37] <JackFrost> kreyren: Different bases, different versioning scheme, etc, etc. You are mixing two different operating systems, it's a bad idea. Just pick one.
2[00:00:46] *** Quits: aloo_shu (~atomic@replaced-ip) (Disconnected by services)
5[00:01:32] <kreyren> can i use debian with testing/sid security and run stable packages? Looking for stable OS to chroot into gentoo/LFS on demand
6[00:02:52] <karlpinc> kreyren: No. You can't mix debian releases. You can run stable and use backports from the backports repo. Or you can backport yourself. What is it that you're really concerned about/trying to do?
7[00:02:56] <n4dir> i am not that sure if testing has security updates, sid sure hasn't. And in general: no.
27[00:10:30] *** Quits: w00dsman (~w00dsman@replaced-ip) (Remote host closed the connection)
28[00:11:08] <kreyren> karlpinc: i can chroot into gentoo assuming it's mounted in /mnt with dev, sys and proc
29[00:11:36] <kreyren> JackFrost: ty helpful
30[00:12:01] <kreyren> what is the recommended release for stable and secure debian/ubuntu distribution? buster?
31[00:12:11] <JackFrost> kreyren: As a slight side note, `arch-chroot` does some of that bind mounting for you.
32[00:12:31] <JackFrost> Buster is current 'testing', which will be the next Stable release.
33[00:12:37] <kreyren> JackFrost: so does my script replaced-url
34[00:12:40] <blackflow> kreyren: the answers you got in #ubuntu about mixing the distros like that were insufficient?
35[00:13:15] <kreyren> blackflow: i wanted to confirm it from multiple sources + figured out which release is ideall for my usecase
36[00:13:22] <karlpinc> kreyren: Sure. But then you're running the rest of the system with different libraries and software. This mostly matters with kernel related stuff, like libc. The kernel and the rest of the system may or may not work or be compatible.
37[00:13:26] <kreyren> blackflow: dont take me wrong you helped a lot
38[00:13:52] <kreyren> karlpinc: sane assuming that i want to run gentoo's ck-sources on debian/ubuntu with optimization to be compatible?
40[00:15:15] <blackflow> kreyren: what use case is that btw?
41[00:15:32] *** Quits: dvs (~hibbard@replaced-ip) (Quit: Din din time! Bye!)
42[00:16:18] <kreyren> blackflow: Expected if gentoo/LFS is hardbricked to use BackupOS to fix it and use GUI
43[00:16:22] <karlpinc> kreyren: An OS has a whole lot of moving pieces. Trying to slap the userspace of one OS onto the kernel of another is not a recipe for happyness.
45[00:16:54] <kreyren> since i'm running gentoo with USE="-*", overdefined make.conf etc.. which needs lots of maintainance
46[00:17:29] <blackflow> kreyren: so like why just not use the gentoo ISO for that? or SystemRescueCD? Why go out of your way to break distros by building a franken abomination even systemd can't rival?
47[00:17:37] <kreyren> karlpinc: there is no problem in making gentoo's kernel work on ubuntu/debian for me but i needs packages with security patches so that i dont have holes in my system when im on backup OS
50[00:18:00] <kreyren> blackflow: systemrescuecd is an option, but i want customized environment in case i end up on gentoo/LFS not working and i need to do work
51[00:18:18] <karlpinc> kreyren: That is what backups are for.
52[00:18:20] <kreyren> problem on ubuntu afaik is that they are slow with updates
53[00:18:36] <blackflow> kreyren: well it just doesn't add up. customized how?
54[00:18:46] <kreyren> karlpinc: backups are not always the solution it's usually just walking around the problem
55[00:19:06] <kreyren> blackflow: so that i can play games, work, etc.. when my gentoo/LFS is hardbricked and it would take time to debug
56[00:19:10] *** Quits: melissa666 (~melissa66@replaced-ip) (Remote host closed the connection)
62[00:20:29] <blackflow> it's a fully usable distro with a lot of kernel features, ZFS included, for you to salvage Gentoo
63[00:20:31] <kreyren> VM is pita since it creates lots of unique issues.. sufficient only for Redox which doesn't have drivers yet
64[00:20:50] <kreyren> blackflow: i dont have games on live iso.. + i need OS on bare metal for my work
65[00:21:15] <kreyren> jmcnaught: i'm multibooting Ubuntu, Gentoo and LFS atm and using chroot to work in LFS and gentoo
66[00:21:33] <kreyren> the problem is security of ubuntu and security of debian in cost of stability
67[00:21:49] <blackflow> kreyren: definitely not something you'd want to mix gentoo, ubuntu and debian into a franken superdistro
68[00:22:17] <blackflow> kreyren: you're also contradicting yourself. building such an abomination is never gonna be stable. I'd deserve standing ovation even if it booted.
69[00:22:22] <kreyren> blackflow: i'm making custom package manager for LFS to use OpenBuildSystem and ebuilds i'm not mixing them together
70[00:22:34] <blackflow> right so you're building your own distro
71[00:22:42] <kreyren> blackflow: what is the best security i can get without sacrificing stability?
72[00:23:05] <blackflow> why do you think those two are in conflict?
73[00:23:34] <kreyren> since rolling distros usually needs lots of maintainance which i can't afford for backup os
74[00:23:35] <blackflow> and this is btw totally offtopic for #debian
76[00:23:53] *** Quits: Rogalian (~cools@replaced-ip) (Remote host closed the connection)
77[00:24:01] *** debhelper sets mode: +l 1519
78[00:24:15] <blackflow> kreyren: so why just not use debian or ubuntu
79[00:24:24] <kreyren> -_- i can't really ask anywhere else and i want to avoid making research about it when it's just a matter of chosing debian/ubuntu distribution
80[00:24:56] <kreyren> blackflow: because ubuntu is slow on updates for security and debian sid/unstable needs maintainance afaik
81[00:25:05] <kreyren> since i want all security updates
92[00:27:10] <blackflow> first of all, ubuntu is rather fast on security updates, and so is debian. they both do, however, triage security impact and won't fix something trivial or unexploitable within an hour of CVE publishing
93[00:27:32] <SerajewelKS> (especially if it breaks things)
95[00:27:52] <blackflow> second, you're putting too much accent on software updates. many critical vulns have existed in systems for months, some years even, before they were discovered/published/patched.
96[00:28:20] <blackflow> at this very moment, there's a number of vulns that will yet be published, maybe tomorrow even. many vulns to come yet will be RCEs, some in the kernel....
97[00:28:31] <kreyren> So what is my best option? I'm using CLIP OS, MUSSQ and PaX kernel patches on gentoo with master packages from updsteam for critical stuff for comparison.. i want something simmilar on debian that is not maintainance heavy
98[00:28:36] <blackflow> so if you're REALLY worried about security, you should put up layers of mitigation that already assume a compromized system
99[00:29:06] <blackflow> what pax kernel patches? you're paying for grsec? or using the terribly out of date 4.9 ones?
100[00:29:26] <kreyren> paying
101[00:29:49] <altker128> Question here: Anyone using Debian LXC containers? I notice my Stretch containers take up ~60-70MB of RAM each with nothing really going on, while a Jessie container is far lower on memory, maybe 10-20MB.
127[00:33:39] <blackflow> well.... "default" being the key operating word here. pletny of gentoo installations with systemd
128[00:33:40] <iovec> it still funny systemd can make the kernel panic
129[00:34:01] <blackflow> iovec: this was even funnier. dbus slagging pid eins
130[00:34:10] <blackflow> oversized message and boom critical hit.
131[00:34:25] <iovec> you don't even have to do much to avoid that
132[00:34:28] <kreyren> my main problem with systemd is that it's too heavy and causing performance issues.. ideally i want OpenRC on debian/ubuntu but that is not a priority now
133[00:34:33] <blackflow> well it's fixed now :)
134[00:34:35] <altker128> systemd seems poorly architected . Still has bizarre symlinks on disk. Should have been written in Go and been a lot cleaner
135[00:34:52] <blackflow> kreyren: irrelevant. point being, your assumptions about "slow updates" in debian/ubuntu are totally misplaced.
136[00:35:01] <iovec> at best if you run supervisor root as non pid 1, you die but everything gracefully reparents to pid 1
137[00:35:10] <iovec> and you get respawned, back to life again
138[00:35:13] <joepublic> +1 "Problem with systemd is: not written in go" -- best criticism I've seen to date.
139[00:35:18] <kreyren> blackflow: recent changes to systemd replaced-url
140[00:35:48] <kreyren> blackflow: so if i'm on cosmic and there is debian update that fixes 150 things when will i get it?
141[00:36:19] <blackflow> kreyren: yeah still not updated, while both debian and ubuntu fixed today (and rhel and centos and fedora ...)
142[00:36:32] <blackflow> kreyren: cosmic and debian have nothing in common
143[00:36:44] <iovec> blackflow: what i find interesting is that focus is on fixing issues, not systematically addressing them.
144[00:36:53] <blackflow> (in relase cadence and package versions AFTER ubuntu branches off every 6 months)
145[00:37:01] <kreyren> ok excluding ubuntu, when i'm on latest stable release when will i get those patches?
146[00:37:09] <altker128> joepublic: It sounds arbitrary but there's a lot of type saftey and intelligence in Go that systemd people had to recreate in C.
147[00:37:09] <iovec> keep playing whack a mole for the next 10 years then, until something replaces you
164[00:39:39] <blackflow> kreyren: I upgraded some servers today, only a few packages were new (systemd included) as those 180 were alraedy there with regular "apt upgrade"-ing
165[00:39:52] <kreyren> blackflow: ah i see, so stable debian should be sane enough to use assuming that security is critical for this system?
166[00:40:15] <blackflow> kreyren: yes but I'd go even further and state use RHEL and SELinux in strict mode
167[00:40:22] <blackflow> if "security is critical"
168[00:40:31] <kreyren> like i have a work there that is worth +-50.000$ i can't affort it beeing compromised
169[00:40:33] <altker128> joepublic: I notice that a lot of "system" software is either low-level and written in C, or written in high-level scripting languages which is flexible but often slow.
170[00:40:38] <blackflow> you'll have less options, less headroom, stricter packages but with that, better security
173[00:41:28] <kreyren> i don't want to use Redhat nor SELinux.. Redhat is for enterprice and requires commercial licence and SELinux is made by NSA
174[00:41:43] <blackflow> so what if it is? it's open source, constantly audited
175[00:41:58] <blackflow> plenty of stuff "made by NSA" and you don't even know about it
176[00:42:04] <FinalX> but nothing will be 100% safe and certainly not immediately.. as good an effort as possible, as always with anything.. not just Debian. you'll always want multi tier security. plus things that shouldn't be online, shouldn't be online.
177[00:42:18] <blackflow> like for example some ciphers in SSL I bet you are NOT excluding
178[00:42:19] <FinalX> pretty sure what we have running on Debian is slightly more valuable than 50k..
179[00:42:20] <joepublic> in my opinion "The NSA are evil beings that I don't like and I don't want to use their software on general principle" is a valid position.
181[00:43:01] <kreyren> rather avoid there is better way to get secure system.. as i said my main problem is to get recent versions of packages meaning if upstream releases new version i want it on my system.. or ideally with the ability to use unreleased like using WINE 4.2 when WINE4.1 is released
182[00:43:05] <blackflow> joepublic: yeah but it's also very much hypocritical
183[00:43:08] <kreyren> for selected packages
184[00:43:22] <blackflow> because then stop using linux. how many patches in it originated in the NSA?
185[00:43:43] <blackflow> and kreyren is using Clip OS which is made by French version of NSA
186[00:43:45] <blackflow> trolololololo
187[00:43:48] <blackflow> hypocrisy much?
188[00:44:10] <kreyren> blackflow: just cherrypicked stuff for it
189[00:44:14] <blackflow> bs
190[00:44:16] <joepublic> blackflow, I respect your position as well.
192[00:44:57] <blackflow> if somoene doesn't want to use "software made by NSA" thenfine. it's not just SELinux, all I'm saying, so be through and stop using software made by NSA completely.
193[00:45:06] <blackflow> *thorough
194[00:45:54] <joepublic> It's a valid position to say "I don't want to use SELinux specifically because of its nature and NSA origin." -- even if you run software containing NSA patches.
195[00:46:03] <FinalX> no matter what you run, nothing is 100% safe.. especially not with cpu's being vulnerable all the time... remotely..
196[00:46:15] <FinalX> so can't rely on *just* the OS
197[00:46:27] *** Quits: RebelCoder (~RebelCode@replaced-ip) (Remote host closed the connection)
198[00:46:35] <konimex> joepublic: wouldn't that be hypocritical?
199[00:46:41] <blackflow> joepublic: no that's just hypocritical. if one said "because it's too complicated, or I don't need it" that'd be perfectly fine.
200[00:47:01] <blackflow> but saying "because herp derp NSA", then stop using otehr things that herp derp NSA :)
201[00:47:21] <blackflow> especially in THIS case, where kreyren is running ClipOS which is......NSA in France.
202[00:47:28] <joepublic> I get the black or white thinking slippery slope idea, but it's possible to want to run or not run something for a combination of reasons that apply to that thing.
203[00:47:33] <kreyren> or like you can always make LFS and build SELinux, etc.. from scratch to make sure it's fine
204[00:48:01] <blackflow> joepublic: that's true but if a reason is "originated from NSA" then please don't stop at SELinux :)
208[00:48:42] <joepublic> What I said was "specifically because of its nature and NSA origin", but don't let that slow you down.
209[00:48:51] <blackflow> like for example I bet the new fangled elliptic curves are all the rage these days for kex and ciphers. well guess where that originated.
210[00:48:53] <Marz> is there a way to be notified when updates are available?
211[00:49:05] <Marz> or do i have to manually check it
212[00:49:07] <joepublic> In fact, I agree, all software is identical in nature, and only your ideas of what should be rejected are valid ones.
213[00:49:07] <n4dir> kreyren: as long you have to ask, stable is the answer.
214[00:49:18] <n4dir> else? else too.
215[00:49:26] <joepublic> Lost my senses there for a minute in reality, but I'm back now.
216[00:49:32] <blackflow> kreyren: btw, selinux is in debian kernel even if you don't use it.
217[00:49:34] <kreyren> n4dir: i dont want to do the research to test invidual releases
218[00:49:37] <jmcnaught> Marz: you can subscribe to the mailing list or RSS here: replaced-url
219[00:49:49] <n4dir> kreyren: i am serious. just stick to stable.
220[00:49:52] <kreyren> blackflow: ik there is lots of wierd stuff in debian kernel thats why i want my own
221[00:50:14] <blackflow> kreyren: so from all said above it seems to me you only needa custom kernel on otherwise regular debian?
222[00:50:22] <joepublic> I am not sure "there is lots of weird stuff in debian kernel" is an accurate description.
224[00:50:41] <kreyren> n4dir: if i gave you a file that is worth 50K $ and tell you to keep it on stable debian and make sure none steals it will you guarantee me that none would be able to get it? assuming that the system is targeted
225[00:50:47] <blackflow> joepublic: there's TOMOYO. TOMOYO is weird. :)
226[00:50:57] <n4dir> kreyren: just encrypt it.
227[00:51:08] <Marz> isn't that just security updates?
228[00:51:13] <kreyren> n4dir: not an option assuming that attacker gain access to unencrypted system
229[00:51:19] *** TxMedic436_ is now known as RedEyeMedic
242[00:52:22] <konimex> damn i just wanted to link that haha
243[00:52:27] <blackflow> really print that out and consult EVERY time when you ask yourself "How secure is this system"
244[00:52:56] *** Quits: Ryushin (chris@replaced-ip) (Remote host closed the connection)
245[00:53:08] <joepublic> that is super good advice imo
246[00:53:52] <joepublic> even an air gap isn't a guarantee; in the past year an air-gapped russian supercomputer was connected to the internet by its low-level operators to... mine cryptocurrency
255[00:57:58] <blackflow> yeah, it dropped 0.0043% in value between those two sentences :)
256[00:58:21] <blackflow> I might haev a zero too many :)
257[00:58:50] <altker128> So, any thoughts on memory usage of Debian Stretch container vs. Debian Jessie container?
258[00:58:57] <altker128> (host is Debian Stretch)
259[00:59:12] <blackflow> kreyren: my advice? if you dislike selinux.... Debian Stable, AppArmor, systemd unit isolation and namespacing options (and seccomp filtering) and above all a good IDS so you can detect breaches.
261[00:59:43] <konimex> looking back at my backlogs of this channel, not doing research just seems lazy
262[01:00:09] <blackflow> altker128: isn't the question really about which processes you run? I mean it's just a namespace. and the diff is probably due to all the bloatware glibc and friends begot between releases
263[01:00:22] <konimex> if one is lazy just use default ubuntu and be done with it, no need to argue or ask back and forth
264[01:00:31] <altker128> blackflow: Well, that's the funny thing, I just mean freshly created containers, nothing installed or running on either after creation time
265[01:00:43] <blackflow> altker128: oh you mean filesystem size?
266[01:00:49] <altker128> blackflow: No, RAM utilization
267[01:01:06] <blackflow> then something MUST be running, a container is just a namespace
429[02:11:11] <karlpinc> Deihmos: Nothing moves to stable. Once it's in stable it stays that way, absent security fixes or other very major brokenness. That's what makes stable stable.
430[02:12:16] <Deihmos> oh
431[02:12:37] <Deihmos> but then you lack new features for years
432[02:14:02] *** debhelper sets mode: +l 1502
433[02:14:37] <karlpinc> !sns
434[02:14:37] <dpkg> Shiny New Shit Syndrome is a serious disorder, which usually breaks out into an epidemic every time something new is released. If you have SNS, ask me about <backports> and <ssb>; these are better options than upgrading to <testing> because it is a <moving target>.
435[02:15:29] <karlpinc> Deihmos: Yes. There are various options. The first question is "is a new feature important enough to have to pay for it with my time, keeping abrest of security, etc.?"
439[02:16:16] <karlpinc> Deihmos: There is the backports repo. Or you can backport yourself. Either way the debian security team does not provide support.
444[02:17:51] <karlpinc> With something like python or nodejs, you use virtual environments to isolate from the OS and an entirely separate set of repos to get newer stuff.
445[02:17:55] <Deihmos> so when buster is released those packages are moved to stable and stay that way until the next release
453[02:20:46] <karlpinc> Deihmos: Mostly, the Linux magic is that you get all your software from a single source -- which ensures that it works. Otherwise, installing from hither and yon your system eventually does what MS Windows does. Turns to mud and must be wiped and re-installed. Many folks here have installs over a decade old, disks moved to newer boxes, disks replaced, until there's nothing left of the install's original hardware.
455[02:22:35] <karlpinc> Deihmos: Of course you should _read_ the release notes of a major Debian release before upgrading. As a rule Debian installs just keep going. Which means my valuable time is not wasted. For that I can (usually) wait a little to get newer software.
456[02:24:13] <Deihmos> so if an app is available in the debian repo but you can also add the source repo you would prefer to stick with debian?
457[02:24:47] <karlpinc> Deihmos: RedHat plays it the other way. Support of a given OS release can last for over a decade. But you have to migrate to a new install to get a new major RH OS release, which is painful.
458[02:24:59] <karlpinc> !tell Deihmos about frankendebian
459[02:25:13] <karlpinc> Deihmos: Yes.
460[02:26:06] <Deihmos> i take it you don't install anything outside of debian repo.
461[02:26:09] <karlpinc> Deihmos: There are a few exceptions. The only one I can think of is the Postgresql upstream repos. The Debian devs are closely involved and they are pretty much guarentteed to work with debian.
463[02:27:21] <karlpinc> Deihmos: I pretty much stick to the debian repos. When I don't I make sure to isolate what I'm doing using one of the tricks on the "don't break debian" wiki.debian.org page.
465[02:28:34] <Deihmos> i see. i guess that's why docker was recommended for what i am doing
466[02:28:36] <karlpinc> Deihmos: Sometimes I self-backport something from sid. But having the security team worrying about security keeps me from having to keep watch.
475[02:33:54] <karlpinc> Deihmos: Debian is also secure because it does not upgrade software and so does not add new security problems. Instead...
476[02:34:01] *** debhelper sets mode: +l 1508
477[02:34:04] <karlpinc> !security backports
478[02:34:04] <dpkg> Debian incorporates security fixes into the version currently in <stable>. This is non-trivial so it may take a couple days. Backporting security fixes means that you can update the package without problems like changed behaviour that would come with updating to a new version of the software. The upstream version number doesn't change in the Debian package when this is done; check the changelog or the <tracker of doom>.
479[02:35:12] <karlpinc> No new software == no new security vulnerabilties
488[02:41:13] <galaxie> Ok, so I finally decided to try and solve my mic issues with Debian. As far as I remember, the internal mic and any mic I had worked perfectly with Windows so unless it broke or something it's probably a Linux thing.
489[02:41:29] <galaxie> It still picks up something.. but it's very faint and mostly a lot of static.
490[02:43:28] <galaxie> Right now I can't find an external mic so I'll just try to fix whatever issues the internal mic is having.
532[03:13:51] <SerajewelKS> galaxie: it might be the dB boost setting, which should be available in alsa as a switch
533[03:14:43] <SerajewelKS> windows also has some built-in enhancements like noise cancelation and beam forming, which generally (AFAIK) the linux sound systems leave to client applications to implement themselves, though you could probably rig something up wich jack and a DAW like ardour, if you also enjoy killing flies with a sledgehammer
535[03:15:01] <SerajewelKS> but based on the problem description it's hard to tell what the issue could be
536[03:16:19] <karlpinc> Deihmos: Nothing wrong with using non-debian software and debian as a platform. You just want to make sure that niether side steps on the other's toes: replaced-url
567[03:34:59] <galaxie> karlpinc: Everything else is in order, but I don't know any oss4 packages. apt-cache search shows only mpg123? Also, I don't see jack sense in alsamixer, do I see it somewhere else?
568[03:36:03] <galaxie> karlpinc: Looks like it's not in Stretch repo even, so I'm good there?
954[08:22:07] <Hypfer> so for reasons unknown to me right after systemd reloaded this morning, it stopped mosquitto
955[08:22:19] <Hypfer> any pointers how to debug this?
956[08:22:30] *** Quits: L1nuxg33k (uid322116@replaced-ip) (Quit: Connection closed for inactivity)
957[08:22:47] <Rico> I'm using serial console cable to connect to a switch (HP comware or cisco). I often have display bugs, using screen or minicom. carriage returns are not displayed
1079[09:24:27] <t3st3r> Rico minicom is quite awful for serial consoles, it inclined on "modems" and does plenty of odd things if it isn't a case. Try e.g. picocom to see if that helps.
1083[09:27:46] <t3st3r> still some strange output can eventually confuse terminal I guess. In graphic desktop it helps to "reset terminal" (at least XFCE terminal provides this feature).
1084[09:29:23] <t3st3r> but my case assumes picocom in graphic terminal -> serial device, etc. Seems you have different case and it may have different pitfalls.
1108[09:42:21] <wrksx> Hey there, I'm using vsftpd to serve some content over ftp, I'm reading the documentation about chroot it says "Warning: This option has security implications, especially if the users have upload permission, or shell access. Only enable if you know what you are doing". I actually have no idea what kind of implications they are refering to, so I'm thinking I don't know what I doing. I'm going to read about chroot a lot, but if
1109[09:42:21] <wrksx> someone could give me a pointer on what kind of security implication ftp+chroot has, I'd be grateful.
1110[09:42:22] *** Quits: andrzejv (~andzej@replaced-ip) (Remote host closed the connection)
1183[10:22:49] <Greyztar> if i got state tracking with related,established then i dont need to open ports to be able to say browse through port 80 and so on,so to speak all traffick originating from the host im running that firewall rule on shoould be allowed?
1188[10:24:23] <Joe_from_next_do> Hello, I see 'broadcom-sta-source' is used over 'broadcom-sta-dkms' in Ubuntu. Searching the internet, I don't find a difference, what would you all suggest I choose?
1200[10:31:46] <Joe_from_next_do> Finally the packages website works again. Was down all morning for me. It says the -source package can be used as alternative to -dkms in case of build problems with the latter.
1289[11:25:11] <shtrb> fdisk say that how many bytes you have written that is the disk size
1290[11:25:23] <oiaohm> shtrb: please don't throw random at flash media the wearleveling may not like you.
1291[11:25:24] <__m4ch1n3__> sk_tandt, startx would lauch X in current tty, dont run startx with sudo you can give executable as argument to startx "stertx /usr/bin/xterm"
1294[11:25:54] <t3st3r> oiaohm> flash supposed to cope with it, at least once.
1295[11:26:07] <t3st3r> or a reasonable # of times
1296[11:26:33] <oiaohm> t3st3r: the answer is no. Some wear leveling in flash media depends on valid MBR being at start of disc.
1297[11:26:59] <oiaohm> t3st3r: make it invalid with /dev/urandom bricked.
1298[11:27:01] <t3st3r> oiaohm> as for systemd, well, systemd prepars arena for new process and shapes it as it meant to be. Who else supposed to parse units?
1299[11:27:02] <blackflow> what does wear leveling have to do with MBR?
1300[11:27:19] <blackflow> t3st3r: a privsep'd subprocess
1301[11:27:22] <oiaohm> blackflow: its just the way some flash firmware is coded.
1302[11:27:40] <t3st3r> oiaohm> that's verrry perverted wear leveling. Seems I'm lucky enough never facing one like that.
1303[11:27:45] <__m4ch1n3__> sk_tandt, add this "systemd.unit=multi-user.target" as kernel boot option
1304[11:28:06] <t3st3r> if it true maybe shtrb needs to write back proper partition table sector :\
1305[11:28:29] <iovec> blackflow: pfft now wouldn't you need a D-Bus interface for PID 1 and subprocess to talk, how is there any other way to pass state around?
1306[11:28:29] <shtrb> well feces
1307[11:28:34] <iovec> absurd
1308[11:28:36] <oiaohm> t3st3r: it was covered at one of the systemd conferences about doing privillages processes under PID1 for the processing.
1309[11:28:42] <t3st3r> <oiaohm> blackflow: its just the way some flash firmware is coded. <- I hope ppl would be kind enough to shot such coders on sight.
1310[11:29:08] <blackflow> oiaohm: any links to support that theory? I can't find any
1311[11:29:17] <blackflow> (then again I haven't yet had my morning coffee)
1313[11:29:59] <t3st3r> shtrb> did you have backup of that sector?
1314[11:30:03] <iovec> oiaohm: No, it was not with the intention to avoid parsing because it would be bad in a privileged context, David's talk happened because systemd blocked on reload too many units
1316[11:30:24] <shtrb> nope :-( didn't expect to need it
1317[11:30:29] <blackflow> iovec: imagine the joke if they actually did? no, wait, don't, something tells me that'd be a fully acceptable and valid thing to do in its devs' mindset
1318[11:30:35] <iovec> they would never bother otherwise, and upstream has already found a solution: allow reloads for individual units
1319[11:30:39] <iovec> so poof
1320[11:30:51] <iovec> blackflow: it's hopeless
1321[11:30:53] <t3st3r> hmm then maybe you can try to recreate it using data about media size from messages you still have :\
1322[11:30:55] <iovec> it's a dead end
1323[11:31:03] <iovec> also: you might want to try out s6
1324[11:31:21] <iovec> (it's difficult to use it but atleast its sane: you don't get everything in life).
1325[11:31:23] <oiaohm> blackflow: I am trying to find the worst ones the worst one for USB flash drivers was not only that it had to have a MBR it had to be fat formated because the flash firmware was reading the fat file systems tables to work out what sectors could be reused.
1328[11:31:45] <blackflow> nah. this is what, one pid-eins-critical-headshot bug in how many months/years? I've had machines hardcrash for a variety of other reasons in that time frame.
1329[11:31:47] <oiaohm> blackflow: flash firmware can be total evil.
1330[11:32:36] <iovec> blackflow: there have been *many* bugs that led ro pid 1 freezing, this is the first one with memory corruption, and this time it became big because kernel would panic.
1331[11:33:01] <blackflow> well, wouldn't surprise me. my USB sticks rarely last longer than a year, even the more expensive ones that are supposedly quality chipsets.
1332[11:33:02] <iovec> so it's making news, there are many on the bug tracker that were silently fixed, there was no visibility given to those
1333[11:33:15] <iovec> (and upstream is known to be hostile to anyone trying to report a CVE)
1337[11:33:49] <t3st3r> <oiaohm> blackflow: flash firmware can be total evil. <- yes, they can. I eventually had funny clashes vs translation on SD card...
1338[11:33:52] <__m4ch1n3__> sk_tandt, would install an window manager which can manage x-session to like obsession
1339[11:34:01] <iovec> there was one where plugging in a device at boot would make it assert, that was _fun_ to deal with.
1341[11:34:24] <blackflow> the CVE thingy... the fact that anyone can file for a CVE is a good thing. like, methinks that 0day bug would not have been fixed if RH did not press for a CVE. the GH issue is a sitcom. "blah blah CVE currency" .... "CVE issued" .... "grumble grumble *fixes it*"
1342[11:34:44] <oiaohm> iovec: I watched david talk he also mentioned it would also help with bad unit files so that the crash when processing unit files would not take the system with it.
1343[11:35:01] <t3st3r> <iovec> (it's difficult to use it <- then to the hell with it I guess. Who needs "solutions" that are "difficult to use"?
1344[11:35:33] <sk_tandt> __m4ch1n3__, doesn't xfwm4 do it?
1361[11:38:14] <oiaohm> t3st3r: IBM policy if the reporter is willing to work them they they cannot be turned down. So it going to be interesting to see how long until Lennart is pulled over the IBM mangement.
1362[11:38:17] <t3st3r> blackflow> linux kernel fixes plenty of things that may or may not be worth of CVEs. I guess merely trying to classify that would take hell a lot of time.
1363[11:38:20] <iovec> the passive aggressiveness is breathtaking...
1364[11:38:39] <blackflow> iovec: yea I've seen that one
1365[11:38:45] *** Quits: elkalamar (elkalamar@replaced-ip) (Remote host closed the connection)
1366[11:39:02] <t3st3r> oiaohm> IBM is cool, etc, but I'm not sure how far integration of RH/IBM is in effect and so on.
1369[11:39:32] <blackflow> t3st3r: maybe. problem is, they're not even trying beause of the "it's all bugs" mantra. I mean, yeah, not ALL things are CVE worthy and sometimes people exaggerate but just part of the same problem
1370[11:39:41] <t3st3r> <iovec> the passive aggressiveness is breathtaking... <- when half of "ancient unix admins" are barking, I guess it hard to stay nice person all the time...
1373[11:40:36] <t3st3r> blackflow> interestingly I would agree it all bugs :). Vulns are merely special kind of bugs, as told by DJB who knows what he tells.
1374[11:40:45] <oiaohm> t3st3r: its going to take a few years before IBM management policies spread into RH.
1375[11:41:20] <iovec> t3st3r: that is a very narrow view, because in the last report nobody backported that PIDFile fix because CVE assignment was delayed
1376[11:41:21] <t3st3r> oiaohm> I've seen some large acquisions so I'm well aware policies do not reshape in a seconds.
1379[11:41:40] <blackflow> and linux is in serious trouble with "we don't break userspace" mantra. bugs cannot be fixed properly due to that. it's getting out of control. replaced-url
1382[11:41:53] <iovec> it becomes much bigger than something about a person, you put all your users at risk
1383[11:42:10] <t3st3r> iovec> look, I've read CVE and after all my personal opinion is that it like 90% of FAIL on d-bus side, and 10% on systemd side.
1385[11:42:25] <t3st3r> Create moron specs - and implementing them going to be a bitch!
1386[11:42:35] <blackflow> I mean how hard is it to DOS the kernel development? find a bug that has been fixed, then lament on the mailing list that it broke your userspace.
1387[11:42:40] <iovec> t3st3r: doing so much in the context of PID 1 is the problem.
1388[11:42:46] <iovec> that's all, anyway, I'm out.
1390[11:43:59] <t3st3r> iovec> and not doing that much in context of PID 1 also been a problem, leading to inability to use plenty of OS features and do hell a lot of things, eventually reinvented by others in many places.
1397[11:46:12] *** Quits: purpleunicorn (uid264544@replaced-ip) (Quit: Connection closed for inactivity)
1398[11:46:15] <iovec> you use a small PID 1, but launch your supervisor under it: you can make it as much of a kitchensink you want, but then if it crashes, all what happens is the little PID 1 restarts it, and all daemons running under it reparent to init
1399[11:46:19] <t3st3r> iovec> where're solutions doing so? Oh, it turns into designing space shuttle and everyone gives up, riding ancient shit instead or some half-assy "solutions" of hell knows what problems?
1400[11:46:29] <iovec> the kernel would not panic, nor would it invoke a killing spree.
1405[11:47:13] <t3st3r> and all daemons running under it reparent to init <- cool, and what happens to e.g. watchdogging/process monitoring at this point?
1406[11:47:19] <oiaohm> blackflow: yes fixing some faults are harder with the Linux kernel policy but not impossible with 5 years time window.
1407[11:47:50] <iovec> t3st3r: it goes away, but the alternative of rooting supervisor in PID 1 means a kernel panic: such a fallback is certainly more graceful.
1408[11:47:55] <t3st3r> so it seems "small" pid 1 wouldn't be so small and have to suck in plenty of features... or fail rather critical aspects. Or not provide it.
1409[11:48:11] <t3st3r> iovec> t3st3r: it goes away <- in this case its EPIC FAIL SHIT.
1410[11:48:37] *** Quits: Haudegen (~quassel@replaced-ip) (Remote host closed the connection)
1411[11:48:39] <t3st3r> Who the hell needs watchdog that does not fires?
1412[11:48:43] <iovec> yeah, a kernel oops is certainly much better?
1413[11:48:46] <blackflow> oiaohm: what the linux kernel needs is a new, full cleanup branch that breaks all promises to the past.
1415[11:49:23] <t3st3r> iovec> hum.... FYI, where it a big deal, my kernels would reboot on this, for example. Running with potentially damaged kernel is a bitch.
1416[11:49:40] <t3st3r> and can cause unknown amount of mischief and data corruption
1421[11:50:26] <blackflow> oiaohm: new branch does not imply dropping support for existing branches
1422[11:50:54] <t3st3r> and systemd at least attempts to seriously plug into even use cases like this. Other not even dared to try - pretending use cases beyond ancient unix do not exist.
1423[11:51:02] <t3st3r> Which is glaringly untrue these days.
1433[11:52:49] <blackflow> other branches can get updated separately
1434[11:52:55] <t3st3r> iovec> yes... this world choosen to be complicated. So these traffic lights near me are running Linux. And it would suck a lot if their management process watchdogging fells apart.
1435[11:53:06] <oiaohm> blackflow: if it not being used by the distributions it not going to get the full CI support.
1442[11:54:21] <t3st3r> <oiaohm> blackflow: bad news here distributions wish to backport patches to older kernels. <- this alone on its own is a big source of security issues.
1443[11:54:25] <oiaohm> blackflow: yes some bad API/ABI in the Linux kernel do need to be marked with deprecated sooner.
1445[11:54:59] <t3st3r> there was number of cases where RH custom kernels were plagued by bugs fixed long ago by upstream. Vulns included.
1446[11:55:13] *** Quits: Fudgey (~blufudge@replaced-ip) (Quit: mIRC with speech 1.0)
1447[11:55:28] <oiaohm> Exactly and trying to get distribution to use newer kernel is not going to happen if the newer kernel does not have backward compadiblity.
1448[11:55:36] <t3st3r> so this world isn't perfect and those who thinks systemd is bit and does a lot of things surely never read Linux kernel source...
1449[11:55:44] <oiaohm> Yes the curse of backwards compadiblity.
1451[11:56:34] *** Quits: __m4ch1n3__ (~m4ch1n3@replaced-ip) (Remote host closed the connection)
1452[11:56:54] <t3st3r> furthermore internal Linux kernel design was never targeting high security or tooling to do that. And we are reaping fruits from that,
1454[11:57:46] <shtrb> let reboot that systemd feces piece of firmware:D
1455[11:57:48] *** Quits: broseph (~broseph@replaced-ip) (Remote host closed the connection)
1456[11:57:51] <oiaohm> t3st3r: true the Linux kernel does a lot but we are starting to see with bpfilter and other usermode helpers and NUMA to reduce how much Linux kernel is doing in single address space.
1457[11:57:53] <t3st3r> Say namespaces are quite bugged and below of what it really meant to be. But to get it right that should be in place from very design phase and earlyest coding.
1459[11:58:42] <t3st3r> oiaohm> BPF alone is a problem when it comes to security. It allows USERS to load date KERNEL SIDE. Now just one extra step to goofy that kernel, and...
1482[12:03:47] <oiaohm> It is depending on the MMU.
1483[12:03:53] <t3st3r> Linux eventually ran even on strange things almost lacking MMU. Say there is STM32 port. At most OS can defend self vs processes using simplified MPU but that's realistically all.
1488[12:04:36] <oiaohm> Please not some of the simple processes that Linux supports really don't have a proper split between ring 0 and ring 3 either.
1489[12:04:42] <oiaohm> not/note
1490[12:05:01] <t3st3r> and I do not really think hardwiring assumptions on how mm/paging/privs happen is anyhow cool idea when it comes to linux.
1491[12:05:07] <oiaohm> when you get into MPU you can have some horrible security problems where userspace to kernel space is more a promise.
1492[12:05:18] <oiaohm> Not hardware enforced.
1493[12:05:46] <oiaohm> Some platforms bpf and userspace are not safe.
1494[12:06:05] <t3st3r> oiaohm> I know. Furthermore, "ring 0" and "ring 3" terms imply its x86. Other CPUs have different names of these features. They not even necessarily map 1 to 1 to x86 notions.
1496[12:06:42] <oiaohm> t3st3r: I am talking about where those features don't in fact exist as hardware seperation in some cpu Linux supports.
1497[12:06:57] <oiaohm> mmu less supports some really horrible things.
1498[12:07:03] <t3st3r> <oiaohm> Not hardware enforced. <- sometimes it actually is. Even with mpu. However MPU just lacks enough entries to separate all processes :)
1499[12:07:35] <oiaohm> So with protections you need the right hardware.
1500[12:07:52] <oiaohm> Good NUMA brings a lot of protections into what we call ring 0 on x86.
1501[12:08:10] *** Quits: elkalamar (elkalamar@replaced-ip) (Remote host closed the connection)
1504[12:08:13] <oiaohm> Linux at this stage has not been using all those features effectively everywhere.
1505[12:08:35] <t3st3r> NUMA is way too HW/arch specific to my taste. And I do like Linux because it cross platform thing.
1506[12:08:53] <t3st3r> I do not think I would ever use Linux if it would be x86-only.
1507[12:09:07] <oiaohm> With hyperthreading and meltdown and spectra is causing a close look at how the Linux kernel allocates page table and shedulers stuff.
1514[12:10:32] <oiaohm> NUMA=non-uniform memory access This is basic term. Key point is the means to assign different memory areas to different cpu cores.
1515[12:10:52] <blackflow> __m4ch1n3__: not per se
1518[12:11:13] <oiaohm> __m4ch1n3__: they are not hyper threading bugs they are cpu prectitive branching bugs. Probing that running on the same core helps.
1519[12:11:34] <t3st3r> oiaohm> and it implies HW can afford it. If it not... do they leave defenceless? Sounds like bad idea. Promoting certain arch and its features arch over others.
1520[12:12:15] <oiaohm> __m4ch1n3__: so how you allocate your cores and memory does effect how well those attacks can work.
1521[12:12:19] <t3st3r> __m4ch1n3__> on very generic level, CPUs attempt to execute several cases of code at once in hope to pick up right one regardless of branch taken.
1522[12:12:54] <t3st3r> This called "speculative execution" and boasted by many different CPUs that are powerful enough.
1526[12:13:34] <oiaohm> t3st3r: It always been the way. You can get risc-v and mips 32 and 64 bit with no idea of userspace and kernel space becaus it will save some silcon being single address space basically full blow mmu less.
1527[12:13:42] <t3st3r> Idea was that effects of losing branch and other stuff like that are completely undone and CPU pretends it never happened. Ironically it proven to be wrong assumption.
1528[12:14:54] <oiaohm> t3st3r: its like the nx flag not all x86 processors back in history support that and not all new processors support it either.
1529[12:14:56] <t3st3r> oiaohm> I guess these are kinda extreme cases. Even STM32 (with official Linux port) does have some separation. That is - exception handlers and related things are more privileged than bulk code.
1530[12:15:22] <t3st3r> And so there're SW fallbacks when CPU lacks HW NX flags as long as I remember.
1531[12:15:47] <oiaohm> t3st3r: but all those software attempt to fix nx flags had flaws.
1532[12:15:57] <oiaohm> t3st3r: to fix lack of nx flags.
1534[12:16:27] <t3st3r> imperfect solution is better than no solution at all - and it would be bad if things only improve on few new cpus and nowhere else.
1535[12:16:32] <oiaohm> Security is a mixture of hardware and software. So much has to be provided by the hardware .
1539[12:17:17] <t3st3r> It is. And hardware is a major problem in this regard. It huge, complicated, all about speed ... and very fragile as the result.
1540[12:17:49] <oiaohm> There is a big problem is that what inside the hardware we have not been able to audit.
1544[12:18:00] <wyoung> Is there an issue with the samba package?
1545[12:18:04] <t3st3r> So that small dumb cpu barely securing kernel from the rest could prove more secured that all that x86 crap, running DMA capable ME firmware side-by-side with all that Linux.
1568[12:27:38] <jim> k-man, you would start another x server
1569[12:27:44] <t3st3r> shtrb> not sure if that enough, kernel could spot it same device. Not sure about that though, but that's why I asked about different port.
1570[12:27:54] <k-man> jim, yes that's exactly what I want to do
1709[13:23:26] <AppAraat> themill: hmm, perhaps a good idea to add that in the documentation? Also I didn't know I could gpg --recv-keys "DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B" "F41D 3034 2F35 4669 5F65 C669 4246 8F40 09EA 8AC3" - perhaps a good idea to add that in the docs as well.
1717[13:26:03] <AppAraat> themill: which one? I only say this format: gpg --keyserver keyring.debian.org --recv-keys 0x673A03E4C1DB921F - which is documented on replaced-url
1745[13:38:08] <de-facto> you mean armhf is build actually on an arm cpu?
1746[13:38:16] <de-facto> the whole thing?
1747[13:38:23] <jelly> and armel and aarm64, yes
1748[13:38:28] <AppAraat> jelly: one downside is that ubuntu offers checksums and gpg keys on their own site over the clear. This reminds me, I should go tell this to #ubuntu-hardened people.
1749[13:38:33] <de-facto> wow doesnt that take ages?
1753[13:39:47] <jelly> de-facto: I guess there's a decent number of build machines
1754[13:39:54] <de-facto> jelly, background of my question: i want to autobuild a deb for raspberry pi on my docker based ci/cd system, do you know of any good toolchain for this?
1802[14:07:09] <de-facto> Can I just do "sudo dpkg --add-architecture armhf" and "sudo apt update" then "dpkg-buildpackage -us -uc -b --host-arch armhf" ?
1803[14:07:16] <de-facto> where does it get its toolchain from?
1811[14:13:33] <muhaha> Can anyone help me with flatpak and debian stretch ? I have server edition. I did: apt install -y --no-install-recommends lightdm flatpak xorg If I run export DISPLAY=:0 ; flatpak run tv.kodi.Kodi its says Invalid MIT-MAGIC-COOKIE-1 keyxcb_connection_has_error() returned true
1817[14:15:26] <themill> de-facto: the current state of the art is on the wiki. Note that if you're building packages for raspbian then this is probably not the way to do it
1819[14:16:49] <toruvinn> actually i probably should've asked here first. does anyone remember that one step im missing from making fcitx/mozc work in my vivaldi (or chrome or whatever, probably)
1820[14:16:53] <toruvinn> seems to work everywhere else so far
1850[14:28:04] <themill> de-facto: there isn't really an official way of doing it as debian doesn't do this at all. This is a commonly used and reliable method, however.
1851[14:28:36] <de-facto> this is super nice with multiarch, i thought i had to build a crosstoolchain for hours...
1852[14:28:46] *** semeion is now known as mnemonic
1904[14:56:49] <Kamiccolo> is there an easy way to add an USB quirk for the device which does not report the state properly? host-powered -> self-powered
1905[14:56:49] *** Quits: boxx (~dickinson@replaced-ip) (Remote host closed the connection)
1910[14:59:24] *** Quits: torisahoneypot (~ERSUqbCDj@replaced-ip) (Remote host closed the connection)
1911[14:59:36] *** Quits: Ede|Popede (~EdePopede@replaced-ip) (Remote host closed the connection)
1912[14:59:39] <blackflow> muhaha: that should've been solved by the DM. if not, then definitely, audio+video+input but eh... with a big warning sign above thatt
1913[15:00:12] <blackflow> (in which it is explained that any user in the group, or any process by that user, can read input/output of any other)
1948[15:09:48] <de-facto> jelly, i wont upgrade stuff but i will prepare a build env so i need apt-get install
1949[15:09:58] <petn-randall> de-facto: you run 'apt-get install nginx' now, and you'll get 1.10.3. If you have "stretch" in your sources.list, you'll still get it in 6 months from now. If you have "stable" there, you'll get 1.14.2, or maybe something newer. You won't be in control of what happens there.
1953[15:10:43] <petn-randall> de-facto: Worse, you'll have drifting state, since you'll have a stretch base OS, but parts of buster installed on it. That's not an approach if you want to do anything serious with it.
1954[15:10:46] <blackflow> muhaha: I'm sorry, I have no idea what kind of isolation issues flatpak poses there, I know it has these "portals" for apps to use system resources, 'sall
1955[15:10:46] <de-facto> i always want the newest release which corresponds to the docker image debain:stable-slim
1957[15:11:02] <petn-randall> de-facto: Then explicitely list it.
1958[15:11:17] <Ede|Popede> oh come on, that's ridiculous. upgrading libreoffice nearly killed my machine? irc gone, no reaction at all for some time, after finally switching to tty i could start htop there. not even there it could be updated while scrolling. and now i have hundreds if not thousands of `^[[C` in the term.log.
1959[15:11:19] <petn-randall> de-facto: You'll have to fix tons of stuff when you move from stretch to buster, anyway.
1960[15:11:29] <de-facto> but then i would have to change Dockefile everytime
1961[15:11:47] <petn-randall> de-facto: "everytime" being every two years, maximum.
1962[15:11:52] <hays> I am having a problem installing redis, dpkg-configure is failing to complete
1963[15:12:06] <petn-randall> de-facto: I'm not forcing you to do it, you can keep it on "stable" and learn from the experience.
1964[15:12:42] <blackflow> de-facto: you'd still have to regularly update your docker images, so what's the problem?
1971[15:13:50] <de-facto> It will be build FROM: debian:stable-slim image everytime with apt-get {BUILDDEPS} so if debian:stable-slim switches to buster i want it to pull in the buster stuff with apt-get without me changing Dockerfile (where i write sources.list)
1987[15:15:58] <de-facto> petn-randall, it will be pushed to my docker registry and pulled by my build system for doing stuff like "make" "dpkg-buildpackage" et al
2044[15:31:46] <hays> at least not in /var/run/redis/
2045[15:31:46] <dpkg> The enter key is not a substitute for punctuation. Hitting enter unnecessarily makes it difficult to follow what you are saying. Consider using ',', '. ', ';', '...', '---', or ':' instead. If you hit enter too often, you will be autokicked by debhelper for flooding the channel.
2047[15:32:51] <blackflow> hays: I wonder if it's a race condition that plagued nginx. I see it installs and works fine in buster. If I used redis, I'd totally change that systemd unit for a Type=simple service, rather than forking. not sure why it's forcing forking
2048[15:32:54] *** Quits: v01d4lph4 (~v01d4lph4@replaced-ip) (Remote host closed the connection)
2055[15:34:19] <petn-randall> I don't believe going back and forth would work. Once you have the backports version, you probably can't downgrade.
2056[15:34:21] <hays> I hesitate to amend my statement. But I'll just say that both are failing in similar ways
2057[15:34:21] <blackflow> hays: oh waitasecond I see it in buster too: redis-server.service: Can't open PID file /run/redis/redis-server.pid (yet?) after start: No such file or directory (but installation did not complain)
2072[15:36:58] <blackflow> hays: I'd change the default systemd unit to start the service as a Type=simple. the config file supports systemd with "supervised" option, explained in the conf
2076[15:38:02] <AppAraat> hi, I flashed debian-9.8.0-amd64-netinst.iso onto an USB stick, then booted from it and installed the system onto another USB stick. Then tried to boot from that USB stick but that failed: replaced-url
2081[15:40:13] <SerajewelKS> is there a standard way to get a system-provided systemd unit to depend on another service? i have a tinc VPN whose up-script adds the interface to a bridge, but tinc services aren't declared to depend on networking, which means that during boot tinc starts before the bridge is up, but is still successful.
2082[15:40:35] <SerajewelKS> the result is a VPN that's "up" and allows VPN connections, but the virtual interface isn't added to the bridge and so VPN-routed packets go nowhere
2090[15:41:46] <blackflow> I really don't understand why the maintainers don't properly use systemd, when they write service units. redis, nginx, more than one example where it's badly used or configured.
2091[15:41:49] <SerajewelKS> karlpinc: i had the thought to stop the specific tinc VPN service on the bridge pre-down and start it on post-up
2106[15:46:26] <karlpinc> SerajewelKS: You make a directory in /etc/systemd/system/... and put a symlink in there. In your case you might want "requires" instead.
2109[15:47:17] <karlpinc> SerajewelKS: There's also a way to override parts of an existing systemd config described there. Another directory is required.
2110[15:48:02] <galaxie> Back again. I finally got my audio in a state to where if I yell, I can hear myself clearly, with some static, but generally I'm not audible enough. Any ideas on fixing?
2111[15:48:15] <SerajewelKS> karlpinc: do you think it would make more sense to have the post-up and pre-down stanzas of the bridge interface manage the service instead since the VPN depends on the bridge?
2112[15:48:28] <karlpinc> SerajewelKS: Overriding would be what you'd do if you wanted to hook into the pre-up and post-down and so forth.
2113[15:48:51] <SerajewelKS> karlpinc: wouldn't i just disable the service so it doesn't auto start?
2114[15:49:02] <SerajewelKS> (trying to understand)
2115[15:49:13] <SerajewelKS> galaxie: does the static sound like background noise, or digital distortion?
2116[15:49:14] <karlpinc> SerajewelKS: There are systemd hooks. That's what I was thinking of.
2118[15:49:46] <SerajewelKS> karlpinc: yeah. just after asking i'm not sure that the .wants mechanism is actually the right solution. but i'm glad you told me about it because i think there are other cases where i do need it.
2119[15:49:50] <galaxie> SerajewelKS: I don't know? It almost sounds like the internal fan, but it could be distortion??
2120[15:50:04] <SerajewelKS> galaxie: hard to tell without hearing it myself. can you record a sample and upload it somewhere?
2122[15:50:09] <karlpinc> SerajewelKS: It's all about having "one place" to look for your configuration. My initial thought is that starting services in the bridge interface is less obvious, since systemd is taking over the world.
2123[15:50:14] <SerajewelKS> though i won't be able to listen until i'm out of the meeting
2124[15:50:21] <galaxie> SerajewelKS: There a nice temp place to do that?
2125[15:50:38] <SerajewelKS> karlpinc: indeed. but when br0 goes down, it doesn't make sense to keep the VPN running; it would have to be restarted anyway when br0 comes back up.
2127[15:51:07] <SerajewelKS> galaxie: if you have a server running an httpd you can use that. or something like S3.
2128[15:51:20] <karlpinc> SerajewelKS: I recall hearing some noise here about the interfaces file going away. (!) I didn't pay attention in the hope that it won't happen. ;-)
2129[15:51:33] <SerajewelKS> karlpinc: though i'm unclear how ifupdown integrates with systemd to begin with
2131[15:51:46] <karlpinc> SerajewelKS: Theory says that systemd takes care of bringing down stuff that requires other stuff.
2132[15:52:27] <karlpinc> (Possibly going away)
2133[15:53:09] <SerajewelKS> side note, i'm not exactly sure how the .wants links that autostart tinc VPNs are generated. the tinc package itself doesn't seem to include anything but tinc.service or tinc@.service and neither of those seem to know how to generate the .wants links
2134[15:53:12] <galaxie> SerajewelKS: I'll just record saying nothing, OK?
2135[15:53:20] *** Joins: paulo (~paulo@replaced-ip)
2136[15:53:38] <karlpinc> SerajewelKS: I always need the systemd "wants" mechanisim when using php-fpm and any other webserver. IIRC.
2137[15:53:48] <SerajewelKS> galaxie: if you can do a sample with and without that would be helpful. but again i won't be able to listen for a bit of time as i'm in a meeting.
2139[15:54:17] <SerajewelKS> karlpinc: hmm. i've never needed that unless the config depends on being able to resolve hostnames or bind to interfaces by name.
2145[15:55:16] <karlpinc> SerajewelKS: I use a Unix socket. I think that php-fpm must have to create the socket before nginx starts. Or the reverse. If you use localhost you don't have an issue.
2147[15:56:39] <SerajewelKS> karlpinc: hmm we're doing the same thing without issue. in my experience nginx doesn't test for the socket to exist and just tries connecting to it on the first request that requires it. if php-fpm isn't up yet then the client gets a 502.
2149[15:57:02] <SerajewelKS> once the socket exists then requests start working without intervention
2150[15:57:25] <karlpinc> SerajewelKS: Maybe I'm not remembering right. There's some dependency somewhere I always seem to need to fuss with.
2151[15:57:35] <SerajewelKS> hmm let me know if you figure it out, i'm curious
2152[15:57:54] <SerajewelKS> i manage a dozen nginx + php-fpm servers and i've never encountered anything like that before. i haven't had to customize anything in systemd.
2153[15:58:02] <SerajewelKS> on jessie and stretch
2154[15:58:05] <karlpinc> SerajewelKS: Could be uwsgi instead of php-fpm.
2158[15:58:17] <SerajewelKS> ah, never used that so i wouldn't know
2159[15:58:48] <SerajewelKS> i'm still puzzling trying to figure out how systemd knows to start my VPN at boot because i don't think i ever told it that, but i don't see anything that generates the service units
2164[15:59:38] <karlpinc> SerajewelKS: If you have a choice, avoid uwsgi. wsgi is fine, but uwsgi documentation sucks -- unless your use-case exactly matches some of the zillion template configs that are in the docs.
2165[15:59:48] *** Quits: ich (~ich@replaced-ip) (Quit: Ex-Chat)
2166[16:00:05] *** Quits: n4dir (~n4dir@replaced-ip) (Remote host closed the connection)
2167[16:00:05] <SerajewelKS> i don't even know what the use case is for uwsgi
2168[16:00:27] *** Quits: conta (~Thunderbi@replaced-ip) (Ping timeout: 240 seconds)
2169[16:00:40] <SerajewelKS> now i'm vaguely recalling tinkering with _something_ about uwsgi or wsgi but i don't remember what it was for
2170[16:00:44] *** Quits: paulo (~paulo@replaced-ip) (Remote host closed the connection)
2171[16:01:16] <godane> so i found out last night that debian live cd iso on usb stick sucks
2172[16:01:58] <SerajewelKS> apparently the tinc README.Debian says to "systemd enable tinc@netname.service" so i guess that's probably what i did
2173[16:02:03] <hays> blackflow: is that the only line i have to change or do i need to read up on systemd
2174[16:02:07] <godane> for some reason the graphics doesn't work and pushs it to 1920x1080
2178[16:03:18] <karlpinc> SerajewelKS: Python. uwsgi is like gnunicorn etc., where it manages wsgi python back-ends and starts and stops them depending on load/etc. Something else (nginx, etc) then handles the http(s) part.
2179[16:03:41] <SerajewelKS> karlpinc: ah hmm maybe it was some django thing i worked on a long time ago
2180[16:03:59] <godane> i also found out once i was able to make aufs and put everything in linux-live scripts stuff start working alot better
2181[16:04:01] *** debhelper sets mode: +l 1572
2182[16:04:16] <karlpinc> SerajewelKS: nginx will hook directly into uwsgi. Otherwise you run, say, gunicorn and reverse proxy.
2183[16:04:18] <godane> video card problems are at least gone
2185[16:04:54] <SerajewelKS> godane: note that you can create your own live CDs with the live-tools project, and you can tell the builder to preinstall whatever you want
2186[16:05:26] <SerajewelKS> a live CD isn't going to come with every tool that everyone wants
2192[16:07:03] <karlpinc> I thought the live project has usbstick images available. Once you've a usb stick image working you can install new packages. If the stick is read-only then you've got to do it every time after boot, but read-write then the packages permanently install.
2193[16:07:17] *** paulo_ is now known as Guest29377
2197[16:09:14] <SerajewelKS> godane: umm ifconfig has been deprecated for years. use ip.
2198[16:10:21] <SerajewelKS> ip commands are less terse but are more precise
2199[16:10:50] <SerajewelKS> e.g. ifconfig doesn't have a way to add an address to an existing interface (AFAIK), you have to use the old-style "virtual interfaces" like eth0:1
2200[16:11:01] <SerajewelKS> with ip it's just "ip addr add x.x.x.x/y dev eth0"
2203[16:11:34] <godane> anyways i'm going to see if can make your image work with extra packages and my live scripts
2204[16:11:48] <SerajewelKS> the startard "ifconfig" output is almost totally superseded by "ip addr" which displays all of the same information except packet counters
2205[16:12:06] <godane> the graphics/videocard doesn't like your livecd for some reason using your scripts
2212[16:13:24] <de-facto> hmm why do i get these warnings "Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:3 and /etc/apt/sources.list:14" after running "dpkg --add-architecture armhf" on doing apt-get install $stuff ?
2213[16:14:14] <de-facto> those line numbers dont make any sense at all
2261[16:34:48] <de-facto> how do i fix warnings like "update-alternatives: warning: skip creation of /usr/share/man/man1/automake.1.gz because associated file /usr/share/man/man1/automake-1.15.1.gz (of link group automake) doesn't exist"
2262[16:35:02] *** Quits: we6jbo (~we6jbo@replaced-ip) (Remote host closed the connection)
2271[16:37:54] <no_gravity> Hello! I connected an USB scanner to my Debian Desktop - how do I know if Debian can see it? In Gimp, there seems to be no new button that lets me scan or something.
2272[16:38:29] <jmcnaught> no_gravity: try the "simple scan" program
2349[16:56:57] *** Quits: galaxie (~galaxie@replaced-ip) (Quit: ircII EPIC4-2.10.6 -- Are we there yet?)
2350[16:57:00] <darxmurf> pffff why the hell I can't connect a samba server using mount.cifs but it works from a windows client? The server is a linux machine configured with SSSD/AD
2351[16:57:11] <darxmurf> oh and it works with smbclient Oo
2378[17:09:22] <Tenkawa> I have an odd one for you all... got a case where if I hook up 64 gb samsung usb thumb drives they perform, sdparm can operate the cache, etc on them just fine... pop in a 128 gb one and it just all goes downhill ad sdparm cant even change the cache states
2379[17:09:40] *** Quits: MenschZwoNull (~MenschZwo@replaced-ip) (Remote host closed the connection)
2383[17:11:11] <SerajewelKS> are they rated for the same version of USB?
2384[17:11:42] <SerajewelKS> i've seen cases where a device claims to support USB3 but malfunctions when operating under USB3. i've had to entirely unload the USB3-related kernel module to force the device to use USB2.
2388[17:12:12] <SerajewelKS> (using a USB2 port also works)
2389[17:12:21] <SerajewelKS> maybe that's worth a try
2390[17:12:28] <Tenkawa> the sandisk "theoreticly" had higher specs
2391[17:12:29] <de-facto> I get a lot of warnings from apt-get install like this: "update-alternatives: warning: skip creation of /usr/share/man/man1/write.1.gz because associated file /usr/share/man/man1/bsd-write.1.gz (of link group write) doesn't exist"
2392[17:12:36] <de-facto> which package am i missing?
2393[17:12:55] <Tenkawa> SerajewelKS: yeah thought about trying that too
2395[17:13:06] <SerajewelKS> de-facto: based on everything you've said, the weird errors, and your refusal to paste your sources.list, my guess is that you are running debian mixed with something else, or not debian at all.
2424[17:16:25] <de-facto> jmcnaught, yes its very minimal FROM: debian:stretch-slim, so I guess i need to install something to make update-alternatives happy
2425[17:16:46] <de-facto> as minimal as possible for building and installing stuff
2426[17:16:56] <Tenkawa> can you paste the error up on pastebin?
2427[17:17:13] <Tenkawa> and the steps taken to reproduce
2428[17:17:24] <jmcnaught> de-facto: so it's a docker image? Sounds like whoever created the stretch-slim image it's based on did stuff like delete man pages, which is why you're getting those warnings
2455[17:24:09] <de-facto> its always the same prefix "update-alternatives: warning: skip creation of /usr/share/man/man1"
2456[17:24:30] <Tenkawa> right because it already exists
2457[17:24:36] <Tenkawa> its prestaged
2458[17:24:51] <otyugh> heya. If some of you did install on SoC ARM devices and got stuck to the "loading kernel..." in the boot process, I'd glad to heard what you did to fix it (using official debian installer). Hopefully you did. (on Olimex A20-micro)
2486[17:33:22] <jmcnaught> de-facto: i don't think those are "official" from the Debian project. Like I said it's likely that the person who made the rootfs.tar.xz that is added by the dockerfile, they probably simply deleted man pages to make the image smaller, and update-alternatives can't find files for man pages that it expects to be there. It's not that serious but makes me wonder what else is changed or missing
2507[17:38:26] <jmcnaught> it looks like Debian developers are maintaining it, but if it were an official Debian project I would expect it to be on replaced-url
2521[17:42:20] <de-facto> jmcnaught, the other one which worries me is "debconf: delaying package configuration, since apt-utils is not installed" but i did apt-get install apt-utils upfront...
2544[17:56:04] <jmcnaught> de-facto: --no-install-recommends could be why apt-utils was missing in the first place, for me "aptitude why apt-utils" shows "debconf Recommends apt-utils". It's a recommend, so it's recommended (obviously) but not strictly required
2570[18:02:58] <nameisjohn> But it seems that when all 4 RAM slots are loaded with the exact same kind of RAM, the system hangs when i open Chromium, although the mouse sometimes still moves around
2571[18:03:27] <nameisjohn> I've tried moving the RAM around, nothing. And any combination of 2 RAMs in either yellow or red channels works fine
2572[18:03:36] <nameisjohn> The old and new RAM really does appear identical
2573[18:03:41] <nameisjohn> So i'm not sure what to do :/
2582[18:05:19] <nameisjohn> sorry i'm still on the "get Debian working today" desicion path, but your right this is nothing to do with Debian. The only thing i can think of is where would a RAM error be stored in the logs?
2583[18:06:14] *** Quits: jesopo (jess@replaced-ip) (Quit: et nos unum sumus)
2619[18:19:11] <de-facto> ok so i would have to wait for buster then i guess
2620[18:19:28] <de-facto> its looks pretty nice there are those packages for "amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x" in buster
2659[18:32:08] <Ede|Popede> did i say 'ridiculous'? what's the next level? klicking on a starterbutton in xfce's panel really shouldn't use all the ressources available. the next disconnect due to the system doing *something* and then org.freedesktop.Notifications gets restarted. never had this before without relation to firefox running wild and now the 2nd time in a day?
2681[18:40:03] <de-facto> when I am inside the source tree of a debian package (directory containing "debian" directory), how can i get the package version in a script (the one from changelog)?
2788[19:35:39] <hays> that's my best guess. do you remember we talked earlier
2789[19:35:53] <blackflow> hays: the solution is very easy. conver the unit to Type=notify, remove ExecStop, and reconfigure redis.conf for supervision systemd
2806[19:41:33] <hays> now im getting: Active: failed (Result: start-limit-hit) since Tue 2019-02-19 13:41:08 EST; 4s ago
2807[19:42:26] <blackflow> hays: in /etc/systemd/system/redis.service comment out ExecStop and PIDFile. Set Type=notify. systemctl daemon-reload. in /etc/redis/redis.conf change supervised to systemd and comment out pidfile. that's it. (re)start redis-server.service
2809[19:43:27] <hays> blackflow: yep. did all that, except i set it to 'auto'. however, it seems like the unit file is in /lib/systemd/system/redis.service
2812[19:44:39] <blackflow> hays: don't change the unit file there. copy it over to /etc/systemd/system/redis.service, or run systemctl edit redis.service
2813[19:44:42] <hays> ok. systemd worked. audo did not
2823[19:46:25] *** Quits: scream (~scream@replaced-ip) (Remote host closed the connection)
2824[19:46:59] <blackflow> if they're the same it doesn't in this case, the lib file will revert on next update or just force it now with apt install --reinstall
2838[19:52:08] <de-facto> how would I "cp" everything (possible even file/folders with spaces) BUT some exclusions into another dir? I dont want to depend on bash et al...
2839[19:53:04] <greycat> oh, you ju.... Oh. You specifically DISALLOWED my answer in your final sentence. Oh well.
2840[19:54:16] <blackflow> rsync --exclude ftw
2841[19:54:35] <de-facto> yeah but thats another dependency
2842[19:54:47] <joepublic> "et al" means "or anything else" which rules out all possible answers.
2862[19:57:41] <greycat> POSIX says there must be an "sh" which must have such-and-such properties, but does not demand that it be in /bin. Because Solaris.
2863[19:57:54] <greycat> Old Solaris put their POSIX shell in /usr/xpg4/bin or something.
2864[19:58:04] <joepublic> and dash, ksh, etc, presumably have posixy properties.
2871[19:59:14] <greycat> As long as you don't have to worry about old Solaris boxes, you can pretty safely assume that /bin/sh will have the POSIX feature set nowadays.
3001[21:04:43] <de-facto> yes thats why i like to use it for exclude patterns
3002[21:04:49] <Tenkawa> I think its the drive... its way hot when I took it out and the metal looks like it might have taken an electrical spike at some point. thank goodness it was on sale
3040[21:10:18] <greycat> embedding the filename inside a larger string is a security hole
3041[21:10:21] <karlpinc> Yeah. xargs -n1 is the ticket.
3042[21:10:25] * Tenkawa prefers xargs
3043[21:10:30] <joepublic> well, unless you are copying a directory full of VMS files called TEMPFILE.TMP;001 and TEMPFILE.TMP;002 etc.
3044[21:10:36] <SerajewelKS> it's hard to walk the line between "doesn't look dumb" and "isn't likely to require special escaping in the case you need to actually literally pass the special token to the command literally"
3045[21:10:46] <greycat> filenames can have newlines, semicolons, backticks, etc.
3046[21:10:50] <SerajewelKS> why did i say literally twice
3048[21:11:41] <joepublic> literally literally means literally usually, whereas literally alone may mean "figuratively, and also, the speaker's vocabulary is substandard or very informal"
3049[21:11:47] <Tenkawa> joepublic: VMS?
3050[21:11:51] <SerajewelKS> i'd rather something look dumb and work right almost all of the time than look great and sometimes work
3051[21:11:55] <Tenkawa> heheh
3052[21:11:56] <karlpinc> I keep thinking that there's got to be an eaiser way than shell. Emacs shell or python shell or something. But my brain always catches on fire.
3053[21:12:26] <joepublic> VMS. It's an operating system. When last I used it, filenames were 8+3+3, filename.ext;ver
3054[21:12:47] <karlpinc> Tenkawa: VMS is the Dec Vax OS. it has the great idea of versioned files.
3055[21:12:48] <Tenkawa> that was the joke
3056[21:12:58] <SerajewelKS> there's some concepts i like about powershell, in particular commands having typed arguments and being able to pipe streams of objects between them instead of just streams of bytes
3057[21:13:12] <Tenkawa> vms was notorious for creating filenames with those names
3058[21:13:18] <joepublic> that "When last" was not recently, by the way
3063[21:14:09] <jelly> greycat: sorry, xargs -0 -n1 -iX do stuff with X
3064[21:14:19] <joepublic> well, it could have been on a PDP
3065[21:14:27] <Tenkawa> indeed
3066[21:14:30] <SerajewelKS> it's somewhat difficult to pipe structured data between programs in a safe way. it obviously has to be encapsulated in some format, like CSV or JSON. then you have programs that don't talk the same language and have to put a translator between them, and all of this carries (de)serialization overhead
3075[21:15:58] <SerajewelKS> powershell lets you pipe objects that don't need serialization, but the downside is that the commands have to run in the same process to be able to access the same memory
3076[21:16:08] <SerajewelKS> so there can be security implications
3077[21:16:26] <joepublic> in same process/same memory/no serializations sounds fast-optimized
3095[21:19:25] <SerajewelKS> whereas on linux all pipes are byte streams, which can convey any data and is simple to reason about, it carries a cost of programs having to format data for the next program that's just going to have to parse it back. the simpler model carries inefficiencies.
3101[21:20:25] <PaulePanter> Hi. With cups-filters packages installed, do you see `/etc/default/cups`?
3102[21:20:46] <Tenkawa> well here's one problem
3103[21:20:51] <SerajewelKS> de-facto: if you mean "insert a fake directory before the structure of the contents" then no, i don't think so. (where would the metadata of this fake directory come from?)
3109[21:21:09] <judd> No packages in stretch/amd64 were found with that file.
3110[21:21:13] <PaulePanter> $ head -2 /etc/modules-load.d/cups-filters.conf
3111[21:21:13] <PaulePanter> # Parallel printer driver modules loading for cups
3112[21:21:14] <PaulePanter> # LOAD_LP_MODULE was 'yes' in /etc/default/cups
3113[21:21:15] <jelly> welp!
3114[21:21:22] <de-facto> somiaj, when i create a tar archive like tar --exclude'.*' -cJvF archive.tar.xz dir <- want to rename dir inside the archive while creatinhg it
3131[21:23:51] <jelly> PaulePanter: a) do you have "cups" package installed and b) wrong channel for sid
3132[21:23:55] <jelly> !debian-next
3133[21:23:55] <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.
3134[21:23:57] <somiaj> de-facto: does your dir have any symlinks in it?
3135[21:24:03] <PaulePanter> commit 24da0c25b9c (Move LP_LOAD_MODULES configuration away from cups to /etc/modules-load.d/cup)
3136[21:24:03] <de-facto> none
3137[21:24:20] <somiaj> de-facto: you could make a symlink with the newdir name, then use -h to follow the symlink
3138[21:24:21] <SerajewelKS> de-facto: note that it's a sed expression
3139[21:24:21] <PaulePanter> jelly: Sorry about that, and thank you for your help.
3140[21:24:35] <somiaj> de-facto: though SerajewelKS suggestion might be more appropriate, I didn't see that in the manpage
3141[21:24:35] <SerajewelKS> Defcronyke: "tar --transform 's/^dir$/newname/'" should work
3142[21:24:54] <SerajewelKS> oh this applies to all filename
3143[21:24:58] <SerajewelKS> +s
3144[21:25:10] <de-facto> that looks very nice actually... let me try :)
3145[21:25:11] <jelly> poor def'cron'thing
3146[21:25:13] <somiaj> I searched the man page for rename, didn't think to look for trasnform.
3147[21:25:41] <SerajewelKS> de-facto: so it would have to be something else that handles 'dir' and 'dir/a/b/c'
3148[21:25:53] <SerajewelKS> regexp gets annoying with optional trailing things
3152[21:26:45] <SerajewelKS> yeah it even documents the options
3153[21:26:49] <SerajewelKS> unlike the gzip manpage
3154[21:26:51] <Tenkawa> jelly: "a"... it probably has like 10 of them
3155[21:26:54] <somiaj> I did test the symlink method, and works for me, but this would only work if you didn't have symlinks inside the archive, as -h will follow all symlinks.
3156[21:26:57] <Tenkawa> all different
3157[21:27:00] <SerajewelKS> oh, they changed that
3158[21:27:07] <greycat> Tenkawa: clearly in context he meant "GNU tar"
3159[21:27:13] <Tenkawa> heheh
3160[21:27:15] <SerajewelKS> gzip --rsyncable used to be up in the usage section, but didn't have any documentation describing what it did
3161[21:27:16] <jelly> but it's GNU tar! GNU people love info
3162[21:27:32] <Tenkawa> I thought they always did
3163[21:27:37] <greycat> Wheezy's tar(1) is dramatically different.
3296[22:14:53] <SerajewelKS> in my experience it's usually TERM not set correctly
3297[22:15:24] *** Quits: Ericounet (~Eric@replaced-ip) (Remote host closed the connection)
3298[22:15:34] <YottaiQ> Dear guys, the operation #SOSNicaragua needs help of all #Anonymous people, please do not leave us alone. Data here =>>replaced-url
3304[22:17:19] <SerajewelKS> same TERM as what? are you saying you changed the font and now line-drawing characters don't display, but they did previously?
3305[22:17:22] *** Quits: AK (~ak@replaced-ip) (Remote host closed the connection)
3306[22:17:23] *** Quits: tradar (~tradar@replaced-ip) (Remote host closed the connection)
3383[22:31:40] <JordiGH> SerajewelKS: I don't actually have a problem with bludgeoning TERM, I don't know what xresources are, and I'm fine. I'm also fine knowing that I had the wrong TERM in a tty. It's not like I actually care about using ttys.
3385[22:32:39] <JordiGH> Why is it that I can't just ask a question and get a precise answer for what I ask without everyone trying to diagnose my ulterior reason?
3386[22:32:43] <SerajewelKS> i mean it's literally just "echo XTerm.termName: xterm-256color >~/.Xresources" but whatever...
3387[22:32:56] <JordiGH> Indeed, whatever.
3388[22:33:02] <JordiGH> It's not something I understand.
3389[22:33:10] <JordiGH> Don't wanna have to maintain that someday.
3390[22:33:10] <SerajewelKS> you asked a question and it was revealed that your config is broken, so we're trying to help you fix it
3391[22:33:18] <JordiGH> Now, bludgeoning TERM, that's something I understand.
3392[22:33:28] <JordiGH> My config is fine, ttys are broken. :P
3393[22:34:02] *** debhelper sets mode: +l 1560
3394[22:34:14] <Sleaker> xterm-256color breaks pagedown for me :(
3395[22:34:22] <Sleaker> have to switch back to xterm sometimes.
3396[22:34:40] *** Quits: Nefertiti (~Nefertiti@replaced-ip) (Remote host closed the connection)
3397[22:34:44] <JordiGH> Can't say that's happened to me.
3398[22:34:53] <Sleaker> err not pagedown, break home/end when in less
3399[22:35:00] <SerajewelKS> JordiGH: hopefully you never have to ssh to this box :)
3400[22:35:02] <flux242> could someone tell me who needs lintian?
3401[22:35:03] <Sleaker> not sure what setting to fix that.
3411[22:36:35] <JordiGH> SerajewelKS: If they want that interpretation, I'm sure they'll request it.
3412[22:36:50] <greycat> Sleaker: it's not a shell syntax file anyway, so you can't source it from a shell. It's used as input to xrdb -merge, normally.
3413[22:36:51] <SerajewelKS> Sleaker: .Xresources isn't even a shell script. it's not remotely the same syntax.
3427[22:38:58] <Sleaker> just forgetting cause I don't use .Xresources very much haha. I think we manually do some xrdb -merge junk somewhere though
3428[22:39:18] *** Quits: dunix (~dunix@replaced-ip) (Remote host closed the connection)
3429[22:39:19] <greycat> You have to know to run the -merge yourself by hand if you edit the file and don't want to restart your X session.
3430[22:39:33] <JordiGH> SerajewelKS: You see, old friend, flux242 didn't wnat to know what this shit was, apparently just wants to know why it's taking up space. I infer (but wouldn't dare assume to be correct) that the goal is to remove lintian and forget about it.
3431[22:39:41] <greycat> So, it's a thing that most Debian users *should* learn eventually.
3432[22:40:37] <SerajewelKS> i've personally never needed to edit an X resource, but that's just me
3433[22:41:02] <SerajewelKS> most of the stuff i tend to use has other, more mature-but-heavy configuration systems, like gconf
3434[22:41:15] <SerajewelKS> maybe mature is the wrong term
3435[22:41:21] <Sleaker> we have some oldschool terminal apps where we have to merge in key overrides
3436[22:41:47] <Sleaker> so we have a key mapping xrdb file we merge in whenever the bash script gets run and then it pops open an xterm window with everything all setup.
3439[22:42:18] <JordiGH> anyway, thanks for help me figure out what the right TERM should be for a TTY.
3440[22:42:21] <Sleaker> so it's useful for that I guess :shrug:
3441[22:42:23] * Tenkawa cringes at his research he's preparing to do for a laptop replacement... to actually be able to play games and be dual bootable
3442[22:42:35] <Sleaker> Tenkawa: why is that cringeworthy?
3472[22:46:31] <SerajewelKS> e.g. you can run your desktop on a low-power GPU then run games on the nvidia GPU
3473[22:46:41] <Tenkawa> I'd be running mine in dual boot
3474[22:46:53] <Sleaker> I think one of the few uses for dual GPU would be to use the second GPU inside of a virtualbox env in passthrough mode
3475[22:46:56] <SerajewelKS> but in practice it just doesn't work well. i have a coworker who tried to get it to work for weeks and it resulted in whole-system freezes and other very undesirable behavior.
3476[22:46:58] <Tenkawa> with the size of ssd's they offer
3477[22:47:03] <Sleaker> so you can run everything basically natively in the VM
3478[22:47:11] <greycat> !optimus
3479[22:47:12] <dpkg> The Bumblebee project aims to provide support for the Nvidia Optimus GPU switching technology on Linux systems. GeForce 400M (4xxM) and later mobile GPU series are Optimus-enabled; if «lspci -nn | grep '\''[030[02]\]'» returns two lines, the laptop likely uses Optimus. Packaged for Debian <jessie> and <wheezy-backports>. replaced-url
3480[22:47:12] <Tenkawa> m.2 and all
3481[22:47:41] <SerajewelKS> i'm sure they're doing a good job developing the software but as of at least last year, it wasn't ready for daily use
3595[23:55:14] <urxtnw> Hello, the difference between apt and dpkg is that dpkg is the lowest level package manager, that doesnt know dependency resolution?
3605[23:57:09] <urxtnw> BCMM so if I want to make something from source I make the package.deb and install it with dpkg correct?
3606[23:57:16] <BCMM> yes
3607[23:57:53] <urxtnw> BCMM I am very confused about apt, apt-get and aptitude, I keep reading articles about them and they are saying it isn't much difference, etc.
3608[23:57:55] <SerajewelKS> urxtnw: you can also 'apt install ./thefile.deb'
3609[23:58:00] *** Quits: Sveta (~svetlana@replaced-ip) (Ping timeout: 246 seconds)
3610[23:58:14] <SerajewelKS> urxtnw: this is particularly useful if the package depends on other packages you don't have installed, as apt will install them for you
3612[23:58:31] <SerajewelKS> if you just 'dpkg -i thefile.deb' it will complain bitterly about the missing dependencies and then you have to 'apt -f install' anyway to fix them
3613[23:58:38] *** Quits: Krennic (~Krennic@replaced-ip) (Quit: Lost terminal)
3614[23:58:50] <BCMM> urxtnw: apt, apt-get and aptitude are mostly interchangeable interfaces to the same system
3615[23:59:07] <BCMM> urxtnw: you can just stick to `apt` commands for nearly everything on modern debian
3616[23:59:11] <SerajewelKS> urxtnw: roughly speaking: apt is the new apt-get. aptitude is a way more powerful tool that even has a full-blown ncurses UI if you run it without any arguments.