Re: [Trisquel-users] How to copy and paste a selected area on GIMP?
It worked. Thanks so maalox.
Re: [Trisquel-users] systemd free trisquel variant?
> [systemd] does too many things. this is contrary to the unix philosophy "Do one thing and do it well". Please refer to the link MagicBanana shared: http://0pointer.net/blog/projects/the-biggest-myths.html This criticism is answered directly as: "10. Myth: systemd is not UNIX." But the underlying claim - that systemd is a single piece of software that does multiple things - is also challenged under both: "1. Myth: systemd is monolithic." AND "6. Myth: systemd is not modular." According to the arguments laid out here, systemd *is* 'many thing, loosely coupled', which means the claim that it doesn't embody the oft-referenced "UNIX principle" is utterly false. I think the burden of proof lies on the critics of systemd to prove that their other claims do not also fail to fit the basic facts.
Re: [Trisquel-users] Trisquel 9 Etiona
I only brought my 32-bit laptop on my holiday to Aotearoa, and due to the pandemic I am now stuck here for the foreseeable future, unable to access my 64-bit laptop in China. Please let me know when 32-bit ISOs are available for testing. FYI I still have a dual boot of Etiona on Bishop, upgraded from a fresh install of Flidas. I haven't stress tested it much but yet, but I have been periodically logging in and applying system updates, and it seems to be working OK so far.
Re: [Trisquel-users] Trisquel 9 Etiona
Taranda: > My system is old If it's old, have you checked it's not a 32-bit system? The amd64 ISOs will not work on 32-bit system. Does Trisquel 8 work on the same system?
[Trisquel-users] Re : Need to compare numbers - Help with script
You can use that AWK program:
{ for (i = 1; i
Re: [Trisquel-users] Trisquel 9 Etiona
Except for the areas with no warning that people accidentally fall into. One example is that Debian makes no effort to steer people to only free browser add-ons. Pop open the browser, end up at the default location, and grab non-free ones without even knowing. I've talked to people that had no idea their add-ons were non-free after I pointed that out. This is only 1 example. Even with something like Debian it's still necessary to keep the shields up.
Re: [Trisquel-users] Trisquel 9 Etiona
> I'd like to use a (semi-)rolling distribution like Debian testing/unstable. AFAIK you can use Debian Testing in full software freedom, as long as you don't turn on any of the nonfree repos.
[Trisquel-users] Re : Can a path statement be too long or the file too big?
Even with the target file moved into the working directory ... so that workaround failed. That is not a workaround. Instead of assuming you are facing limitations or bugs and trying random things, you had better read the documentation and understand what you do wrong. Without option -F, grep interprets every line in the pattern file (in argument of -f) as a regular expression. For instance, '.' means "any single character". Is it what you want? As usual, it is very hard to understand your problem and I got tired of deciphering your vague text with no example of the input and of the related desired output. Anyway, I doubt grep is the proper command to use here. It looks like a task for awk or, if the order does not matter, for join (or even comm).
[Trisquel-users] Need to compare numbers - Help with script
So, I have a file with dozens of lines like this 12 13 59 2 102 12 32 2 99 13 102 19 I need to compare if any of the numbers in first line are present in the second line. Then I need to compare if any of the numbers of the second line are in the third. And so on and so on. I don't want to count if the same number appears in both first and third line (13 for example is not to be counted in my example above). Position is not important (number 12 is in first position in the first line, but second position in the second line, I still want to count it). I have been looking at ways to do loops but not sure how to build an array for this (not even sure if an array IS the best option). Any help is greatly appreciated, I usually do well with bash but this time around it's proving more difficult. Thanks!
Re: [Trisquel-users] Laptop lid linked to power management
This seems to be more a hardware issue rather than a software issue. I'd try another distro just to confirm this behavior is the same with any other distro (debian or trisquel live should do the trick)
Re: [Trisquel-users] Wifi Qualcomm Atheros AR9287 does not work on Debian 10
Hi, I just tried debian testing kde downloaded from this link http://ftp.icm.edu.pl/pub/Linux/distributions/debian-cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-kde.iso and the problem is the same as in debian 10.4 stable. When I try it live, I still can't activate my wifi. I don't want to reinstall a system for the third time on my disk and not be able to activate the wifi, I will stay in debian 9 until someone publishes a tested and effective solution to this problem. Thanks
Re: [Trisquel-users] Can a path statement be too long or the file too big?
Pressing on to delve into another part of the project ... Again another grep script in the same vein worked very hard for about twenty minutes and then disgorged the original target file in its output, using an increment of 4.7GB of RAM. Even with the target file moved into the working directory ... so that workaround failed. Faced with no alternative, this lazy semi-geek condensed the target file to a simple one-column list (which he ought to have done at the outset) and re-ran the grep script on the condensed target, with the happy response of a slowly rising output file (rising in kB incrementsrather than multi-MB), the same RAM usage (the additional 4.7GB), and usage of 520kB of SWAP, which it had not done before. Grep again took about twenty minutes to accomplish all this. Grep was clearly going through the same motions each time, but somehow its actual output has gotten overwritten in the first instance, but was protected in the second run. The target file was 63.5MB in the first run and still 26.5MB the second time, but now the output file has real grepped data without superfluous material, about 3MB and 71,000 rows of non-duplicated matching PTR's. One difference between yesterday and today is that the pattern file now has nearly 4,000 hostnames. What should I be seeing with the terminal ? dmesg |tail or dmesg |more
[Trisquel-users] Re : Can a path statement be too long or the file too big?
grep has no "internal limit": as long as the currently processed line (not file) fits into main memory, it works.
[Trisquel-users] Re : Laptop lid linked to power management
I had understood the problem is with the interrupter on the lid: it must be damaged. I thought you could just tell the OS to "do nothing when laptop lid is closed" (and could use Fn+Fsomething, or the menu, to suspend). Isn't "do nothing" a possible action in Xfce's power manager? It is in MATE's. That said, the laptop "shuting off instantly" suggests the OS cannot prevent it: that behavior apparently bypasses the OS, as pressing for a long time the power button does. You should then try to discover where the interrupter is and block it on the "lid opened" position.
Re: [Trisquel-users] Laptop lid linked to power management
I'm using XFCE rather than MATE but XFCE's power manager has options for what to do when the laptop lid is closed (Switch off dislay, Suspend, Hibernate, Lock screen) for both plugged in and on-battery modes. None of these address my laptop's behavior, which is to *shut off when moving the lid more than a centimeter*. And I mean shut off instantly, not a controlled power-down sequence. Just: power is gone. Inversely, when the laptop is off I can open the lid and the power button lights up and the laptop boots up as if I had pressed the power button. Sometimes I have to wiggle the lid a little to trigger this.
Re: [Trisquel-users] Can a path statement be too long or the file too big?
After thinking about my observation last night, it dawned on me that the script has to reach down through the directory structure of the host computer before negotiating the directory structure of the flash drive. Let's articulate that structure in the scripts as though they were being run from arbitrary working directories: grep -f /home/george/Desktop/May2020/nMapScans/Pattern-File-A.txt /home/george/FlashDrive/...4 steps.../Target-File-A.txt > Output-File-A.txt versus the unsuccessful script: grep -f /home/george/Desktop/January2020/DataSets/MB/Multi-addressed-HNs/Counts/Pattern-File-C.txt /home/george/FlashDrive/...4 steps.../Target-File-B.txt > Output-File-B.txt and after moving the target file: cd /home/george/Desktop/January2020/DataSets/MB/Multi-addressed-HNs/Counts ; grep -f Pattern-File-C.txt Target-File-B.txt > Output-File-C.txt Analogously to moving a multi-gigabyte file: mv hugefileA.txt /home/george/someplaceelse/folderB/folderC/hugefileA.txt which takes just the blink of an eye so long as the move takes place within the file structure of the storage medium, all that really matters is the number of characters in the path statement. The multi-megabyte target file moved in just a few blinks of an eye and can be moved back to its flash drive just as quickly ... I actually copied the file, so I can just delete it and then clear the trash file. In the present case it was painfully obvious that the unsuccessful script wasn't inaccurate or noisy but plainly wholly unsuccessful instead, as the output file was the exact same size as the target file. This is not a bug; it's a feature that is necessary for an historic or practical reason, whatever that may be.
