[04:20] good morning [11:48] hello i have an idea for nautilus [11:48] i want to find some people to help me work on it [11:48] anyone know the code base? [11:48] lets hear your idea Guest13 [11:48] well [11:48] lets say you do long file transfers [11:49] that usually isn't something that happens all the time, but it happens often enough that i think nautilus could improve the experience [11:49] well currently if it runs into a situation it can't handle on its own it asks for user input [11:49] skipping, merging, etc.. [11:50] well i think these events could be placed into a queue and still allow the transfer to continue [11:50] if it is a directory obvious child events would be adopted into the queue [11:50] Guest13: you want nautilus to behave like filezilla for example with queues? [11:51] im not familiar with that functionality on filezilla [11:52] Guest13: when you say transfers, wich ones do you mean? [11:53] any transfers really from 1 disk to another or which ever [11:53] usb drive to home directory etc.. [11:53] right [11:53] this allows the user to walk away from the computer, but then still handle those situations and not lose time [11:56] Guest13: file a wishlist bug against nautilus, see what happens [11:56] do you know where i should do that at? [11:56] Guest13: think this is what you need right? https://askubuntu.com/questions/44725/how-can-i-queue-file-operations [11:58] no i dont think so [11:59] what i am thinking of is more of a stack you can push and pop file copy operations that require user input, but it still continues to transfer the other files while waiting for user input [11:59] if you are familiar with the programming term of a stack [12:00] you just place those operations that require user input to the side [12:00] the user can still interactively put their input in for those operations [12:00] at any time [12:00] but it just doesn't hold up the transfer process [12:00] not sure they will add a feature like that into nautilus [12:00] but you are free to try, you are member of the ubuntu community [12:01] lets say you are transferring a large set of files and you have 1 file that already exists and it occurs in the middle of the transfer process [12:01] you go to sleep [12:01] when it starts [12:01] because it will take 5 hours [12:02] you come back and it is only half way done because the file copy operation program requires your input [12:02] you just lost 2.5 hours [12:02] because the software isn't intelligent enough to put user input operations to the side [12:02] sorry but the smarter user would just transfer into a separate directory and handle the merge themselves after [12:03] well the smartest thing is to transfer nothing ever but we all know we do not live in a perfect world [12:03] no i'm pretty sure file transfers will always exist as a task [12:03] right [12:03] which is why file copy/paste should be smarter [12:04] it is a left-over from 1990s; such conflicts should be queued to the end and reported together [12:04] disagree but nevermind, there's coffee to be made :) [12:05] but so much in GUI land is designed to be serialised not parallelised [12:05] yes creating more threads is easy and not that expensive [12:06] but i know many people probably work on nautilus [12:07] Guest13: gcp does what you talk about (puts problems aside and continues with other files) [12:07] we got a similar issue in ubuntu upgrades, asking the user a lot of keep/upgrade packages, so you cant goto sleep neither [12:07] cool i will try and keep that in mind [12:08] lotuspsychje: yes; for config file conflicts; hence why packages should use the /etc/.d/ process so package-installed files aren't edited, you just add additional local config files [12:09] the system is called *something*-parts (dir-parts ?) but cannot recall it now [12:09] oh, run-parts [12:09] TJ-: i recall lts upgrade from bionic to focal asked me tons of stuff [12:09] that's for executable scripts though [12:10] lotuspsychje: the other reason for questions is when upstream have removed options and the package configure scripts have to change things in ways that aren't automatic [12:11] i see, but its not really friendly for beginning ubuntu users [12:12] there's nothing else to be done [12:12] Guest13: anyway, wishlist bugs you create with; ubuntu-bug nautilus from terminal and explain your story/wishlist [12:12] you cannot queue such questions into a batch since they're per-package configure-time issues that need resolving [12:12] TJ-: but i must say, after all the choices, the upgrade went pretty fine [12:13] later packages may depend on those being fully upgraded [12:13] at lease package maintainers do the work to let us know these breaking changes need sorting out :) [12:13] yeah true that [12:14] I've seen things like postgresql removing options with no 1:1 replacement, for example, so you have to do some research before deciding what to do [12:14] especially for a LTS>LTS d-r-u [12:19] yeah i bet server upgrades are even more complex TJ- [12:32] which is why they need practicing on a disposable clone :) [12:56] tomreyn: /please/ quiet/kick/ban mundelj ! already been banned from #hamradio and #linux for spamming despite being warned [13:02] he's on holiday [13:05] really?how dare he! [13:07] i know! in fairness we did get warning, he's off slaying the Alps single-handed ;) [13:08] slacker! :D [13:08] I need about 6 months off :) [13:09] well you can try and submit the form to us, i'll run it by my cat but i wouldn't hold my breath if i were you... [13:10] hehehe [13:10] My brains are leaking out my ears [13:10] we might be able to budget for an absorbant hair net? [13:10] Been working on integrating kerberos+ldap+tls+sasl+gssapi recently [13:11] hmm that's a lot of puzzle pieces [13:11] indeed [13:11] took 2 weeks to get it into a sane state [13:15] Allie mundelj has already been banned from #hamradio and #linux for spamming despite being warned, mostly verbal diahorreah unrelated to the channel topic. After the #linux ban joined #ubuntu and started but since a few warnings has been quiet in that channel. I'm not in -offtopic so sounds like user focused there [13:16] he's also banned from #linux-offtopic due his behaviour [13:16] if they're shutting up after warnings, i'd consider that a success - I have eyes now. [13:16] Allie: also, ignores repeated requests to stop [13:17] but whilst quiet, yes, hopefully it stays that way [13:17] i will say if they're spouting nonsense but otherwise not being massively disruptive, /ignore is a *wonderful* tool, as is just not engaging them [13:17] Allie: well that's the problem, after warnings he didn't shut it [13:17] trolls get bored when people don't respond to them, and in my experience that is far more effective than a kick or a ban [13:18] Allie: ^^^ and on support channels many users don't know about /ignore but yes, my attitude is to not respond [13:18] TJ-: aye, but it seems they're mostly shutting up in #ubuntu now. [13:18] but it's like a DNS amplification attack; annoying user says 1 thing, then 5 people tell them to stop, et al [13:18] aye. [13:18] Allie: yes, as I said, sounds like they focused on another channel :) [13:19] they seem lonely. /ignore them and let them vent for a bit and they'll get bored and go away [13:19] Should say this user has been doing this for about a week in various channels now :) [13:19] presumably in others I don't frequent [13:19] Hey. [13:19] yup. i've made a note, and will keep an eye on it. [13:20] Mekaneck: but honestly, stop engaging them and see what happens [13:20] ^^^ [13:20] Allie: roger [13:21] cheers :) ties our hands when someone continues to engage their disruption. [13:21] on a side note the ops command of ubottu should really be updated ... it lists people that havent been active in #ubuntu for a decade or more 🙂 [13:21] well that was a nice distractoin from Kerberos! [13:21] can't ubottu just check the channel access list for that? [13:22] dunno, perhaps ask #ubuntu-irc ... IIRC they maintain it [13:23] i put him on ignore, had enough of the guy for this afternoon [13:23] Mekaneck: you had to get the last word in, tho? [13:23] that's not super helpful... [13:23] couldn't help it, just fed up [13:24] hence i put him on ignore [13:24] you absolutely can help how you engage with disruptive users on IRC [13:24] s/engage/don't engage/ [13:25] bah, flammable/inflammable :P [13:27] :D [13:45] oh look at that, they got bored and toddled off! [13:45] :) [14:34] did they? [14:36] maybe not [14:42] that's why i said it... not [14:43] here we go again ;) [14:48] he's lucky i'm no op there, otherwise he'd be histroy already [14:49] histroy/history [14:49] Allie: I'm sorry, but this "ignore them and let them vent for a bit and they'll get bored and go away" is a really horrible way to manage a support channel and to deal with these idiots. Then victim-blaming anyone who asks them to stop and tries to alert the proper people to deal with it. This has gone on for years in #ubuntu and literally never works and pisses off those that have volunteered most of those years [14:51] agreed leftyfb and besides that they are getting annoying again in offtopic i see [14:51] I see that [14:51] i'd say get rid of them now K-line and done [14:52] it's been going on long enough now to piss others off [14:53] other channel ops have been faster with banning them today so why not in the buntu channels [14:54] ubuntu members were standard ops in all channels, except #ubuntu iirc [14:55] not in -offtopic [14:55] oh, right [14:57] aaand, there goes the nuclear option. they had a chance :) [14:58] that was not nuclear and can and has been abused [14:58] right, and if they continue to be disruptive, they'll be dealt with accordingly [14:59] by quieting them? a ban would have been more appropriate by now imho after all those hours [14:59] quiet only means they can't post directly. In the past, trolls have continued their antics by changing their nick repeatedly or sending a notice to the channel or /msg'ing people directly (last one only being prevented by a kline of course) [15:00] leftyfb: I am intimately familiar with our trolls here on Libera. We'll take the actions we deem appropriate, when they are appropriate. [15:00] But given the fact that I've only seen what I've seen, I'm inclined to take the same escalating steps I do in channels I'm *actually* staff in. [15:01] Allie: right, and that is the topic at hand. For years the "appropriate" manner in most cases has been to allow them to spew for hours on end, then eventually "ask" them to stop, sometimes going AFK immediately after asking. [15:01] I have /umode +g [15:01] if anyone who's explicitly an op wishes to take more extreme action, they're absolutely welcome to. [15:03] But I think it's pretty important to assume good faith even if someone is being a significantly disruptive element, and take the minimum necessary action to deal with the immediate problem - that was, the drivel. [15:04] now they can spout into a /dev/null buffer and nobody needs to care. If they *do* end up following other avenues of abuse, well, I have so many other pretty buttons I can press. [15:04] Allie: you underestimate the drive of a troll. I've seen trolls come back and continue their same antics after 20 years [15:05] Well. I probably won't be staff here in 20 years :) [15:06] (to be clear, it wasn't on Freenode/Libera) [15:08] Allie: are you an op in #ubuntu? [15:08] I'm network staff, I opered up to clean up the mess [15:08] Allie: quiet him in #ubuntu too please [15:09] aaand, now they catch the ban [15:09] thanks [15:10] I gave them their chances [15:10] yup