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.