| lotuspsychje | good morning to all | 04:15 |
|---|---|---|
| Sveta | https://www.vice.com/en_us/article/8xzj45/someone-is-spamming-and-breaking-a-core-component-of-pgps-ecosystem | 04:33 |
| Sveta | i don't understand it... | 04:33 |
| Sveta | who cares who signed my key? if i already shared it with my friend and he knows it belongs to me, everything else doesn't matter | 04:34 |
| lotuspsychje | https://access.redhat.com/articles/4264021 | 04:37 |
| lordievader | Good morning | 06:15 |
| lotuspsychje | hey lordievader | 06:16 |
| lordievader | Morning lotuspsychje , how are you doing? | 06:16 |
| lotuspsychje | all good lordievader tnx | 06:16 |
| ducasse | good morning | 06:17 |
| lotuspsychje | we had an interesting issue in main, tsimonq asking about spam signed gpg key | 06:17 |
| lotuspsychje | <tsimonq2> Fun keyserver-related question that probably belongs here. | 06:17 |
| lotuspsychje | <tsimonq2> My GPG key was signed by some spammers, and I would like to remove the spam signatures. | 06:17 |
| lotuspsychje | <tsimonq2> I currently hold my GPG private key, so I hope this is still possible | 06:17 |
| lordievader | Interesting. Why would spammers sign keys though, what is in it for them to do so? | 06:19 |
| lotuspsychje | lordievader: this seemed interesting: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f | 06:21 |
| lordievader | Oh, that is quite bad. | 06:30 |
| lotuspsychje | not sure i understand the spammers reasons yet | 06:31 |
| lordievader | Reading the sks post you just gave, this might be a way to DoS a lot of things... the whole debian/ubuntu package infra comes to mind... | 06:37 |
| lotuspsychje | yeah this really doesnt sound good.. | 06:38 |
| blackflow | wait, what does this mean really, that the KSK infra is effectively blown out, public keys can no longer be trusted? | 06:54 |
| blackflow | *SKS | 06:55 |
| blackflow | yeup.... boom. "stop retrieving data from the SKS keyserver network" | 06:56 |
| lordievader | They can still be trusted, they just might break the implementation you are running. | 06:56 |
| blackflow | I'd call that very much untrusted :) | 07:00 |
| blackflow | besides, from reading about it in detail, there's no way of knowing which signatures are legitimate and which are poisoned, so yeah, no go. | 07:07 |
| RikMills | lotuspsychje: wow @ Simon's GPG key! | 07:35 |
| lotuspsychje | RikMills: yeah its nuts | 07:35 |
| blackflow | After re-installing 18.04.2. from scratch, I forgot to disable STUPID, MORONIC, IDIOTIC unattended upgrades that just upgraded Firefox behind my back and the thing crashed while I was trying to send an email via webmail. | 07:46 |
| blackflow | "A system designed for idiots is only usable by idiots" | 07:46 |
| marcoagpinto | Hey | 07:49 |
| marcoagpinto | guys?! | 07:50 |
| lordievader | 👋 | 07:51 |
| marcoagpinto | the software I am coding has the GUI showing okay on 18.04, but on versions above the panel gadget becomes bigger and the gadgets inside it go a few pixels below | 07:51 |
| marcoagpinto | :) | 07:51 |
| marcoagpinto | should I check for Linux version or GTK version to fix it | 07:51 |
| marcoagpinto | for example, in Ubuntu 18.10+ I want to add more pixels to the panel gadget to compensate it takes more space | 07:52 |
| marcoagpinto | ? | 07:52 |
| blackflow | Which package do I file a bug against, that pertains to default installed packages? | 07:56 |
| lotuspsychje | what kind of bug are you encountering blackflow | 07:56 |
| blackflow | unattended-upgrade being installed and enabled by default | 07:58 |
| RikMills | A bug in a default package? Or you disagree with the default choice? | 07:58 |
| RikMills | Oh, that | 07:58 |
| lotuspsychje | wishlist against linux perhaps? | 07:58 |
| blackflow | the kernel? | 07:59 |
| lotuspsychje | blackflow: or against unattended-upgrades itself? | 08:00 |
| RikMills | That fact that it is installed, would be a seed issue. So probably file against Ubuntu desktop meta package (though that change is likely in platform/core) | 08:00 |
| lotuspsychje | ah | 08:01 |
| RikMills | The fact that it's enabled by default, could be against the package itself, of perhaps a default settings package | 08:01 |
| blackflow | lotuspsychje: problem is unattended-upgraes is not tracked by launchpad | 08:01 |
| lotuspsychje | !info unattended-upgrades | 08:01 |
| blackflow | RikMills: yeah it can be installed by default, just not enabled. | 08:01 |
| ubot5 | unattended-upgrades (source: unattended-upgrades): automatic installation of security upgrades. In component main, is optional. Version 1.1ubuntu1.18.04.11 (bionic), package size 40 kB, installed size 384 kB | 08:02 |
| lotuspsychje | blackflow: is this wish for server? | 08:02 |
| RikMills | blackflow: huh? https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades | 08:02 |
| blackflow | RikMills: Now add /+filebug to that URL and hit enter | 08:02 |
| blackflow | "unattended-upgrades does not use Launchpad as its bug tracker. " | 08:02 |
| blackflow | ah, must file against the source package | 08:03 |
| blackflow | https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+filebug | 08:03 |
| RikMills | blackflow: yep | 08:03 |
| blackflow | bug 1836328 please mark if you agree | 08:08 |
| ubot5 | bug 1836328 in unattended-upgrades (Ubuntu) "unattended-upgrades should not be enabled by default" [Undecided,New] https://launchpad.net/bugs/1836328 | 08:08 |
| luna_ | Listening to this weeks episode now: http://ubuntupodcast.org/2019/07/11/s12e14-sega-rally-championship/ | 08:09 |
| blackflow | Changing/modifying software without direct user intervention used to be called Malware. Back in the day only compromised systems modified its own software unexpectedly. And then Ubuntu came... | 08:13 |
| lotuspsychje | blackflow: affected & added to -discuss team | 08:16 |
| blackflow | much obliged. | 08:16 |
| lotuspsychje | blackflow: someone set your bug to wontfix | 09:35 |
| lotuspsychje | oO | 09:35 |
| blackflow | of course :) | 09:36 |
| lordievader | Wasn't this a somewhat recent change? | 09:37 |
| lordievader | As in the enablement by default. | 09:37 |
| blackflow | I think it is yes, but I can't pinpoint it. I usually install via debootstrap and never include that thing. | 10:05 |
| blackflow | It's now also a default in debian Buster it seems. | 10:05 |
| RikMills | someone = member of foundations team | 10:24 |
| BluesKaj | Hey folks | 11:26 |
| marcoagpinto | BluesKaj!!!! | 11:32 |
| marcoagpinto | Hello!!! | 11:32 |
| BluesKaj | hi marcoagpinto | 11:32 |
| marcoagpinto | I was doing some exercises | 11:32 |
| * lotuspsychje sighs | 13:39 | |
| lotuspsychje | jelly: so wich Os would that be? | 13:43 |
| jelly | lotuspsychje, sorry, apparently I had reached the join channel limit and had to choose which channels to give up, to join here | 13:43 |
| jelly | lotuspsychje, debian | 13:43 |
| lotuspsychje | jelly: so you advice to eolupgrade debian to the next version, without warning the security part? | 13:43 |
| jelly | lotuspsychje, absolutely | 13:44 |
| tomreyn | hehe, reached the channel limit, that's already tough on freenode. | 13:44 |
| blackflow | lotuspsychje: what warning? | 13:44 |
| jelly | it's set to low 120 channels. | 13:44 |
| tomreyn | :) | 13:44 |
| lotuspsychje | blackflow: if the eol system has been taken over | 13:45 |
| blackflow | lotuspsychje: I don't follow you | 13:45 |
| jelly | lotuspsychje, the security issue is exactly the same whether you have, say, left an unpatched bionic for a year, or left an unpatched artful for a year | 13:45 |
| lotuspsychje | lets take 17.10 as example, alot of usn came out since, the system could be compromized | 13:46 |
| lotuspsychje | would you still trust that system? | 13:46 |
| jelly | that applies to 18.04 as well. | 13:46 |
| blackflow | "could" yes... but how likely is it. | 13:46 |
| lotuspsychje | blackflow: but how can one be sure? | 13:46 |
| blackflow | your running LTS "could" be compromised right now with a zero day nobody knows about but the attacker. | 13:47 |
| jelly | lotuspsychje, would you trust it LESS than an unpatched 16.04 or 18.04? | 13:47 |
| blackflow | you can't be sure here either. | 13:47 |
| blackflow | I'd just hate to jump to conclusions. | 13:47 |
| lotuspsychje | jelly: this is not about lts or non-lts | 13:47 |
| lotuspsychje | its about eol versions | 13:47 |
| jelly | lotuspsychje, I'm not suggesting the user to keep running an unsupported release. | 13:48 |
| lotuspsychje | jelly: i know, but you cant be sure its hacked or not | 13:48 |
| lotuspsychje | so why take the risk? | 13:48 |
| jelly | lotuspsychje, you can't know if your xenial has been hacked, EITHER | 13:48 |
| jelly | there's no functional difference. | 13:48 |
| lotuspsychje | thats true, but thats why we advice users to keep system up to date | 13:49 |
| lotuspsychje | jelly: plus, this user didnt want to update | 13:49 |
| jelly | lotuspsychje, does "please go from 17.10 to 18.04" not count as "keep system up to date"? | 13:50 |
| lotuspsychje | not much we can advice anymore | 13:50 |
| lotuspsychje | volunteers adviced him to eolupgrade | 13:50 |
| jelly | okay. I misunderstood you as "don't eolupgrade" | 13:51 |
| lotuspsychje | no i did not | 13:51 |
| tomreyn | jelly: when someone comes to #ubuntu with an eol'd version we almost always use the !eol factoid , which also points to !eolupgrade - and we often trigger that, too. | 13:53 |
| BluesKaj | sometimes these cement heads just want to troll, they know they're eol, but afraid to admit it so they become aggressive | 13:54 |
| tomreyn | and sometimes, if the user seeks to upgrade, we also help them do so. | 13:54 |
| tomreyn | or they are pentesters but have no idea about what they're doing. | 13:55 |
| blackflow | lol.. this discusion is to teh contrary -- not recommending eolupgrade to "such old systems". | 13:55 |
| lotuspsychje | 60 pages of !usn since ubuntu 17.10 do i need to say more? | 13:56 |
| tomreyn | i think it's perfectly fine to recommend a fresh installation over an unsupported release upgrade path | 13:57 |
| blackflow | lotuspsychje: and how many unfixed for Bionic? https://people.canonical.com/~ubuntu-security/cve/main.html | 13:57 |
| lotuspsychje | blackflow: i never claimed a fully updated system isnt a risk neither :p | 13:57 |
| lotuspsychje | but that doesnt mean we cant warn users about risks | 13:58 |
| lotuspsychje | like tomreyn said, the !eolupgrade factoid also needs a rework | 13:59 |
| blackflow | !eolupgrade | 14:01 |
| ubot5 | End-Of-Life is when security updates and support for an Ubuntu release stop, see https://help.ubuntu.com/community/EOL for more info. Looking to upgrade from an EOL release? See https://help.ubuntu.com/community/EOLUpgrades | 14:01 |
| tomreyn | launchpad is partially down. this is not a bug - at least not one you can currently file on launchpad. :-P | 15:02 |
| * RikMills blames swift | 15:04 | |
| blackflow | tomreyn: aww, you defanged some nice jokes now :) | 15:05 |
| tomreyn | surely you mean the bank transfer system | 15:05 |
| blackflow | ColdFusion(tm) | 15:06 |
| tomreyn | maybe there'll be updates on https://twitter.com/launchpadstatus if it'll last some hours. | 15:06 |
| tomreyn | or here https://lists.ubuntu.com/archives/launchpad-announce/2019-July/thread.html | 15:07 |
| blackflow | they upgraded the underlying os from Stretch to Buster? :) | 15:10 |
| tomreyn | rather from 12.04-PATCHED to 14.04-PATCHED | 15:14 |
| blackflow | oof! | 15:17 |
| tomreyn | i made this up, really. but i did see 12.04 version numbers on at least one of those servers while 12.04 ESM was active - which can be fine. | 15:20 |
| tomreyn | it's certainly not an easily maintained infrastructure. | 15:21 |
| blackflow | best opportunity for Canonical to dogfood their products ;) | 15:22 |
| tomreyn | it's already back | 15:26 |
| OerHeks | ohh https://store.steampowered.com/app/226840/Age_of_Wonders_III/ free to keep if you get it before the 15th | 15:46 |
| Eickmeyer | People need to stop reporting bugs against PPA packages. | 16:13 |
| Eickmeyer | !bug is <reply> If you find a bug in Ubuntu or any of its official !flavors, please report it using the command « ubuntu-bug <package> » - Please do not use this to report bugs against packages acquired from PPAs, contact that !ppa owner. See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs. | 16:13 |
| OerHeks | bug reporting against a snap is also fun | 16:14 |
| Eickmeyer | Heh | 16:14 |
| Eickmeyer | At least once a day I"m getting bug reports for GIMP when someone either 1) installed from a PPA, or 2) attempted to compile it themself, it fails to compile, and they file it against the version in the repo. >.< | 16:15 |
| blackflow | Eickmeyer: I thought launchpad was trying to become central place for more than just ubuntu main repo packages. | 16:19 |
| tomreyn | now (how) will they know whether their package is from a PPA, this is yet to be explained, i guess? | 16:19 |
| tomreyn | apt policy packagename, but it wont fit into this factoid | 16:19 |
| blackflow | I don't get it. Why not report bugs to LP for PPA packages? | 16:20 |
| Eickmeyer | blackflow: Yeah, but only if the PPA maintainer sets it up themselves. 'ubuntu-bug {package}' simply files it against the package in the repo, nowhere else. | 16:20 |
| blackflow | Not sure I follow | 16:21 |
| Eickmeyer | tomreyn: Most people add PPAs themselves for newer versions of software, so they would know they installed it from a PPA. If they don't, then they shouldn't be messing with PPAs to begin with. | 16:21 |
| blackflow | for example if I wanted to file a bug against nvidia-driver-430 from the graphics PPA... what would I do? | 16:22 |
| Eickmeyer | blackflow: using 'ubuntu-bug {package}' files it against lp:ubuntu/+source/{package}. That doesn't apply to PPAs at all. | 16:22 |
| Eickmeyer | blackflow: Contact the PPA owner. | 16:22 |
| popey_ | We have looked at adapting apport type programs for snaps, for sure. | 16:45 |
| hggdh | blackflow: yes, the sequence is adjust apport so that it is able to deal with snap-specific BTS (at _least_ point to the user where to go) | 16:46 |
| hggdh | popey_: heh | 16:46 |
| blackflow | I'm telling you , nobody is gonna bother registering and filing bugs against dozens of different trackers. NOBODY. | 16:46 |
| popey_ | As I said, that's already the case. | 16:46 |
| popey_ | Statistically speaking, nobody files bugs. We know this already. What's the news here? | 16:47 |
| blackflow | it's also the case that users who would otherwise file a bug, won't. like me. I file whenever I find an issue, at LP. will I do the same for snaps? with no central place? nah. I won't bother. | 16:47 |
| popey_ | Your loss. | 16:47 |
| hggdh | I agree the major risk on snaps (or flatpaks, for that matter) is publish & forget | 16:47 |
| blackflow | popey_: I doubt that. I just won't use the snap. it's not as if I can't get software outside of it. | 16:48 |
| blackflow | (in context where the snap doesn't work or something) | 16:48 |
| popey_ | Great! | 16:48 |
| blackflow | hggdh: as years of docker has shown. | 16:48 |
| hggdh | let's move a bit, and compare with IOS/Android. Where do you file bugs for a third-party application (i.e., *not* Apple or Google)? | 16:49 |
| blackflow | popey_: I hope you realize that attitude toward users who would like to contrib with bug reports, is really just gonna result with the whole ecosystm becoming like windows, degrading into an unusable mess. PPAs redux. | 16:49 |
| popey_ | Or windows apps, or mac apps? | 16:49 |
| hggdh | ^ | 16:49 |
| popey_ | blackflow: which attitude? | 16:49 |
| blackflow | the one you're showing here. | 16:50 |
| popey_ | I'm showing indifference because it's a monumental waste of time trying to convince you of anything, that's very clear. | 16:50 |
| popey_ | So why should I bother? | 16:50 |
| hggdh | what can snapcraft do: if an application is misbehaving badly, remove if from the store. If an application does NOT provide a BTS link, warn the user, clearly, that there is NO support | 16:50 |
| blackflow | I'm not asking you to convince _me_. Im just telling you that without a central place for us users to file bug reports, even us who otherwise would, will NOT because nobody is gonna bother with dozens of different accounts at dozens of different trackers. | 16:51 |
| popey_ | I completely understand your perspective, and politely disagree. | 16:51 |
| popey_ | I think you're exaggerating for hyperbole sake. | 16:51 |
| popey_ | Nobody signs up to "dozens of different trackers". Nobody. | 16:51 |
| blackflow | well that's my point. | 16:52 |
| popey_ | People sign up to one or two here and there for specific issues that annoy them | 16:52 |
| popey_ | Right, my point is that's already the status quo! | 16:52 |
| blackflow | so the takeway here is that snap store won't bother with a central place to report issues because nobody is filing them anyway, and upstreams mostly have their own? | 16:53 |
| popey_ | No. | 16:54 |
| popey_ | The takeaway is that developers have their own trackers, so why not use them. | 16:54 |
| hggdh | no, this is not it. a distribution centre is NOT the same as development. You distribute, you do not support | 16:54 |
| blackflow | I think we're going in circles here.... | 16:55 |
| popey_ | The vast majority of users already do not file bugs. Enthusiasts do. You might not. This is not the end of the world. | 16:55 |
| hggdh | e.g., you go to (say) Best Buy and buy a laptop; if, later on, the laptop mishehaves (or -- say -- Windows misbehaves) you go to the manufacturer, not Best Buy. And yes, I know this is sort of contrived | 16:56 |
| blackflow | hggdh: uhhh no. Here in EU I take it to the store where I bought it as I've got warranty.... | 16:56 |
| hggdh | blackflow: yes, we are sort of going in circles. We do not agree with you, and we are trying to show why | 16:56 |
| blackflow | in fact, if I tried to call the manufacturer, they would just tell me to contact the store where I bought it. | 16:57 |
| hggdh | blackflow: so you return your laptop to the store cuz it is BSOD-ing. What will the store do? | 16:57 |
| blackflow | hggdh: the stores here take it for diagnostics and repair. | 16:57 |
| hggdh | blackflow: so let's keep on. The disgostics come back saying it is a software failure. Then what? | 16:58 |
| blackflow | let's not. this is now strawman and outside of scope of the example you were trying to make. | 16:59 |
| hggdh | ok | 16:59 |
| popey_ | We have written blog posts, and spoken directly to developers telling them how to optimise their store page. | 17:00 |
| popey_ | Part of that is linking to bug trackers. | 17:00 |
| popey_ | If we had a central tracker, we'd be middle men where their bugs go to die | 17:00 |
| popey_ | Hello launchpad :D | 17:00 |
| blackflow | And now, hello "Even less people are gonna bother reporting bugs". | 17:02 |
| popey_ | We'll see :) | 17:02 |
| blackflow | hggdh: the part about strawman... a snap is a whole product. there's no hardware-software dychotomy. it's all software.... there's no parts the user can install into the snap and break the warranty. | 17:04 |
| blackflow | ie. if you "take back the snap to the store, for repairs", the vendor can't shrug. Eithre the software in the snap is broken (vendor's responsibility), or teh snap framework is broken. | 17:06 |
| hggdh | blackflow: who is the warrantor? | 17:06 |
| popey_ | Who is the best person to tell, when the software is broken? The person who made it. | 17:06 |
| popey_ | ergo, their bug tracker | 17:06 |
| blackflow | just like with real hw laptops from teh orig example: the vendor is. vendors have agreements with distributors who have agreements with stores, to cover the warranty. | 17:07 |
| popey_ | Ooh, it's the weekend. Time for beer | 17:07 |
| popey_ | Cheerio! | 17:07 |
| daftykins | enjoy, sir \o | 17:07 |
| hggdh | popey_: cheers | 17:07 |
| blackflow | I never said that bugs should not be reported to vendors. I merely questioned the _place_ where such reports -- to vendors -- are made. | 17:09 |
| blackflow | if you're gonna force users to hunt down upstream trackers (which'd require registering and whatnot) -- good luck with people wanting to do that. I don't think I'm being unreasonalbe or hyperbolic with that statement. | 17:10 |
| daftykins | TJ-: wb, happy Friday \o | 17:12 |
| pragmaticenigma | TJ-: ready for weekend support? | 17:14 |
| hggdh | blackflow: no, not forcing users to hunt down. The sore could (as said before) enforce developers to clearly indicate where to get support | 17:17 |
| hggdh | s/sore/store/ | 17:19 |
| daftykins | do any of you folks have contact with debian for bug reporting an upstream bug? apcupsd has a bad default parameter in the shipping .conf that causes IRQ error spamming | 17:21 |
| daftykins | i just installed buster in a VM to confirm - this stems from bug 1781016 | 17:21 |
| ubot5 | bug 1781016 in linux (Ubuntu) "Slow flood of do_IRQ: No irq for vector" [Medium,Incomplete] https://launchpad.net/bugs/1781016 | 17:22 |
| tomreyn | you don't stricrly need 'contact with debian' for this, other than be able to send mail to bugs.debian.org | 17:22 |
| daftykins | well yeah i just figured it'd be a nice shortcut | 17:22 |
| tomreyn | making them send that e-mail? ;) | 17:22 |
| tomreyn | https://www.debian.org/Bugs/Reporting | 17:23 |
| daftykins | yes i'm on that page right now, which is what had me thinking email was an incorrect choice to begin with | 17:23 |
| tomreyn | there is no other way than e-mail AFAIK | 17:23 |
| tomreyn | reportbug also uses email | 17:23 |
| tomreyn | use an e-mail address you have good spam filters on | 17:24 |
| daftykins | nope i'm just not going to bother, then | 17:24 |
| tomreyn | or that ;) | 17:25 |
| daftykins | just seen how many are sat open against the package as it stands... | 17:25 |
| blackflow | daftykins: you can file for Ubuntu too, there's a section in the bug tracker for Debian as a distro for the package | 17:25 |
| daftykins | are you sure there'd be any point, given it just comes from upstream and a considering reply 23 on the above? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1781016/comments/23 | 17:26 |
| pragmaticenigma | daftykins: whta is the work around? I'd love to remove those! | 17:26 |
| daftykins | -a | 17:26 |
| ubot5 | Ubuntu bug 1781016 in linux (Ubuntu) "Slow flood of do_IRQ: No irq for vector" [Medium,Incomplete] | 17:26 |
| daftykins | remove what? | 17:26 |
| daftykins | it's already described on the above bug, commenting out the serial device line | 17:27 |
| daftykins | so essentially the default shipping config has USB and serial enabled out of the box, which isn't too smart | 17:27 |
| tomreyn | comment 23 is what's to be expected whenever you file a bug against a package imported from debian (which is not in main / restricted) | 17:27 |
| daftykins | yes but that doesn't answer to me whether there's anything to be gained by what blackflow suggested :) | 17:28 |
| tomreyn | true. in my experience such bug reports will just sit there. | 17:28 |
| blackflow | mine got resolved in a few hours today. both for ubuntu AND debian. | 17:30 |
| tomreyn | though there can be exceptions. such as when it's a security bug and the security team has some time to handle it beyond handling main + restricted (which does happen). | 17:30 |
| blackflow | they're very fast when the solution is EWONTFIX. | 17:30 |
| daftykins | that's why i'm very demoralised on bug reporting in general, pretty much everything i've ever had a hand in has sat for years | 17:31 |
| tomreyn | can't say this for myself. | 17:32 |
| lordcirth | I've had widely varying experiences on that front. | 17:32 |
| daftykins | well i'm sure you've done a lot more than me | 17:32 |
| lordcirth | from less than a day to never | 17:32 |
| tomreyn | ^ that's my experience, too. | 17:33 |
| lordcirth | There's also the intermediate "someone came by and set priority, area, bug type, etc" and then nothing | 17:33 |
| blackflow | I've had mixed results too. | 17:35 |
| daftykins | if i'm honest about the above i was embarrassed not to have spotted it myself, mind you | 17:35 |
| tomreyn | less than a day is really rare obviously. never is not uncommon. what's in main or restricted is usually handled sooner or later, though, depending (not only) on criticality + impact | 17:35 |
| lordcirth | Ah, I was talking about bugs in general, not Ubuntu or whatever specifically | 17:35 |
| blackflow | btw.... weird that default LTS ISO installer would install you non-LTS kernel.... just occured to me. | 17:57 |
| tomreyn | which one's that? | 17:59 |
| tomreyn | and which kernel did it install? | 18:00 |
| daftykins | yeah what do you mean? the 18.04.2 image will install 4.15 unless you specifically select HWE from the boot menu | 18:02 |
| OerHeks | blackflow, on vbox .. | 18:02 |
| blackflow | tomreyn: I got the HWE 4.18 one, fresh new installation of 18.04.2 | 18:02 |
| blackflow | OerHeks: yeah, saw that lol | 18:02 |
| blackflow | daftykins: I did not select anything special | 18:03 |
| tomreyn | blackflow: so you got linux-image-generic-hwe-18.04 - which will track the latest HWE kernel image until 18.04 EOL | 18:04 |
| tomreyn | the kernel version + abi will change though, yes | 18:05 |
| blackflow | yup | 18:05 |
| blackflow | I was just surprised to see it installed by default. That and nvidia-driver. | 18:05 |
| daftykins | i thought you had to specifically pick HWE from both legacy and EFI boot methods, ah well | 18:10 |
| lotuspsychje | bionic has now default 4.18 kernel on iso from downloads | 18:11 |
| tomreyn | i think you have to on a d-i installation, not on ubiquity, not sure about subiquity | 18:11 |
| lotuspsychje | the one that boosted my ssd's :p | 18:11 |
| tomreyn | https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=get&target=18.04.x+Ubuntu+Kernel+Support+Schedule.svg | 18:12 |
| lotuspsychje | handy tomreyn tnx | 18:13 |
| tomreyn | even more so, showing how things changed twice since 14.04 https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kernel_Support | 18:14 |
| tomreyn | actually they changed once only :) | 18:14 |
| blackflow | lotuspsychje: oh btw... I saw no difference with my boot times aftre reinstalling .2 from scratch. | 18:17 |
| * daftykins installs from 18.04.1 media and sticks to the stock kernel if newer hardware support isn't needed | 18:23 | |
| * blackflow is a sucker for latest and greatest. | 18:23 | |
| daftykins | confessed version number chaser eh? :) | 18:24 |
| blackflow | yeppers. | 18:25 |
| tomreyn | two days ago, but i missed this update: https://twitter.com/ubuntu_sec/status/1149150094836396032 | 18:29 |
| sarnold | blackflow: in a meeting.. more in a bit | 18:34 |
| blackflow | sarnold: np | 18:34 |
| blackflow | tomreyn: this about ZFS on 5.x kernels is what's worrying me wiht HWE... I'd rather stay with 4.15 then until 20.04 and 0.8.x ZFS which I think has the , or will have, regressions fixed. | 18:40 |
| lordcirth | If I don't run the latest of everything, how am I supposed to know everything I can by the time it's prod-ready? XD | 18:41 |
| sarnold | blackflow: so.. I'm personally afraid that the kernel devs removed the fpu symbols to set a lawsuit trap | 18:57 |
| sarnold | blackflow: one of the other distros put together a patch to reexport those symbols and it's my own opinion that canonical is too much of a lightning rod to use that patch | 18:58 |
| blackflow | sarnold: gentoo is for example, yes. | 18:59 |
| sarnold | thanks, yes, that's the patch :) I couldn't recall who did it | 18:59 |
| blackflow | but I doubt the kernel devs are doing this as lawsuit bait. afaik they're very vehemently against involving courts in GPL violations. | 18:59 |
| sarnold | I've seen enough comments over the years in support of harald welte's lawsuit that I have drawn a different conclusion there :) | 19:00 |
| blackflow | That the VMWare lawsuit? | 19:00 |
| blackflow | huh no, that's some other lawsuit. | 19:01 |
| blackflow | but anways, both GHK and Linus are against GPL lawsuits. I think this is just to mess with commerical vendors that'd use ZFS as they probably wouldn't want to risk anything. Methinks the devs hate ZFS. | 19:03 |
| blackflow | but I think ZFS is just gonna reinvent those functions through SPL. For now, as a quick patch, they just made ZFS buildable under 5.x, but I haven't been following the dev so close in the past month or two, so I don't know what's new there. | 19:04 |
| sarnold | oh I *know* the devs hate zfs :) | 19:05 |
| blackflow | shame. it's really the best FS in the whole ecosystem, for now. btrfs is barely a shadow to zfs, and bcachefs is a joke that'll take at least 10 year to reach ZFS grade maturity, if at all. | 19:08 |
| lordcirth | btrfs has, afaik, exactly two advantages over ZFS. Firstly, it's easier to install to a btrfs root than a ZFS root, but that's more a matter of distro support. Secondly, it deals well with mismatched drive sizes. | 19:09 |
| sarnold | a few weeks ago I saw a comment like, "if you want zfs to work fast, reimplement it with a clean license, and use our framework for snapshots, raid, etc" and .. the whole point of zfs is that it's just so much *better* | 19:09 |
| blackflow | lordcirth: those are advantages yes, but it's instability and buggyness drowns those out | 19:09 |
| blackflow | *its | 19:10 |
| blackflow | sarnold: that's never gonna happen. OpenZFS still wants it to be cross platform which demands it not depend on any kernel features (too much). | 19:12 |
| blackflow | which also shows how alien ZFS is in Linux. but eh... | 19:12 |
| sarnold | blackflow: heh, yeah. | 19:12 |
| sarnold | I *really* hope we can sort out something good before 20.04. It'd be a real shame if that's 20% the speed of 18.04 zfs and five times the CPU use.. | 19:13 |
| blackflow | sarnold: back to DKMS and patching out GPL symbols :) | 19:13 |
| blackflow | that does not violate GPL. | 19:14 |
| sarnold | blackflow: yeah, that's true. that ought to be good. it's also more complicated and brittle :( | 19:15 |
| blackflow | hmmm, dunno, I've got a few debian machines with root on ZFS on LUKS too and those work flawlessly. In fact, I upgraded just today one of them to Buster, it went smooth and glitchless. | 19:17 |
| sarnold | I'm glad to hear that :) for my new laptop I've done the root on zfs on luks route and omg I'm glad for rlaager's excellent guide | 19:19 |
| sarnold | I made two typos in crypttab I think that took me *hours* to track down. | 19:20 |
| sarnold | and the whole time I was thinking "I should just do this over with ext4 like a normal person and not hate this choice in two years" :) | 19:20 |
| blackflow | heh. I got one step further, custom initramfs script for remote unlocking via SSH which also does optional rollback for rpool, should an upgrade bust boot. | 19:20 |
| sarnold | wow :) | 19:24 |
| === guiverc2 is now known as guiverc | ||
| TJ- | Is ZoL really that stable? 110 open defects currently | 22:07 |
| OerHeks | and benchmarks are not that great either https://www.phoronix.com/scan.php?page=article&item=freebsd-zol-april&num=1 | 22:11 |
| sarnold | doing good benchmarks is hard; there's so many conflicting results there that don't make sense to me that I'm inclined to write off the entire article as not very informative | 22:44 |
| sarnold | all those results showing ext4 *slower* than zfs are a cause for concern: I would want to know what about the workload lets that make sense. | 22:45 |
| TJ- | copy-on-write possibly | 22:46 |
| EriC^^ | some folks will waste precious time of volunteers on a definition saying it's misleading and cause havoc as if world war 3 broke out cause of a wrong definition, maybe you should read more, here have fun https://unix.stackexchange.com/questions/346425/what-is-the-difference-between-a-hard-link-and-a-file/346575#346575 "This leads to the statement that every directory entry is actually a hardlink, and that hardlinking a file just means to create a seco | 22:59 |
| EriC^^ | nd (or third, or fourth...) hardlink. In fact, each inode stores a counter for the number of hardlinks to that inode." enjoy blackflow but please refrain from EVER speaking to me the way you did today or in any manner what so EVER. i wont tolerate your actions and you've taken stuff too far for too long. be warned | 22:59 |
| EriC^^ | tfeh | 22:59 |
| OerHeks | https://www.gamingonlinux.com/articles/ubuntu-lts-releases-and-so-derivatives-too-to-get-updated-nvidia-drivers-without-ppas.14557 | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
