I felt like fixing a thing in qtcreator and tried git clone https://code.qt.io/qt-creator/qt-creator.
It took over 2 hours to reach 13%. I thought there may be a problem with using https or maybe it was just a network thing, so I tried gi clone git://code.qt.io/qt-creator/qt-creator.git and it turned out to still be as slow.

While normally opening code.qt.io and using the cgit was pretty snappy, with git, I am getting an average download speed of 10KB/s.

• Is this how the server is normally configured?
• Is this only happening with me or do others have the same experience?
• Did I just get unlucky and try to download during the a maintenance day?

Similarly, git clone https://code.qt.io/qt-creator/perfparser was also as slow. Although it finished in under 10 minutes because it was a small project.

cross-posted from: https://programming.dev/post/43343171

I just started checking out auditd and made a rule to log file accesses.

auditctl -a always,exit -F dir=/path/to/my/directory -F perm=rwa

From the output, I got some things that might be useful:

• The full path of the executable
• pid
• Parent's pid: ppid
• Process' current working directory cwd

Now if the process was still running when I check the logs, I could open htop and find out what exactly called the process, from the pid.
For example, say I run a git pull on a repository and find out that /usr/bin/ssh is accessing some file, I will get something like:

st
└ bash
    └ git
        └ ssh

I will get the full executable path of each executable (and know if the executable was not in the system directories, but in some unsafe location writeable by another user). This will give me enough context to go by.

But using this same example, what happens if I check the logs after the git operation has ended?
The git process ppid will have been lost(?) and I would have no way to know which process called ssh.

How do I solve this condition?
Ideally, I want to have the audit log contain the whole calling tree with the full executable path of each parent.

I just started checking out auditd and made a rule to log file accesses.

auditctl -a always,exit -F dir=/path/to/my/directory -F perm=rwa

From the output, I got some things that might be useful:

• The full path of the executable
• pid
• Parent's pid: ppid
• Process' current working directory cwd

Now if the process was still running when I check the logs, I could open htop and find out what exactly called the process, from the pid.
For example, say I run a git pull on a repository and find out that /usr/bin/ssh is accessing some file, I will get something like:

st
└ bash
    └ git
        └ ssh

I will get the full executable path of each executable (and know if the executable was not in the system directories, but in some unsafe location writeable by another user). This will give me enough context to go by.

But using this same example, what happens if I check the logs after the git operation has ended?
The git process ppid will have been lost(?) and I would have no way to know which process called ssh.

How do I solve this condition?
Ideally, I want to have the audit log contain the whole calling tree with the full executable path of each parent.

Title

ffmpeg ... -c:a flac -exact_rice_parameters 1 -multi_dim_quant 1 ...

I was encoding wav to flac.

• With default options, the result was almost instant
  • At > 500x speed
• Used -compression_level 12, finished in ~ 7 seconds
  • speed = 48.9x
• Then I used multi_dim_quant
  • After ~ 10 minutes, I checked the speed to be ~ 0.02x. So thought it would take an hour or so. 1.30 seconds worth of audio was encoded
  • It's been over 2 hours now.
    • Shows 1.46 seconds of audio encoded with current speed = 0.00017x

Considering running it in a VM, so I can "pause" it whenever I need to restart my computer.

Update:
size= 123KiB time=00:00:02.82 bitrate= 356.3kbits/s speed=4.68e-05x
It stopped trying to use layman notation.
I'll need to restart soon-ish, but I'll see how far this goes and if the 2.82 seconds of audio is even listenable.

cross-posted from: https://programming.dev/post/34025065

DeviantArt Link

Endless Sky is and open source game. This animation is inspired by the compass image that shows up on the menu screen.

CC BY-NC-SA 4.0 : https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en

Used stock https://github.com/endless-sky/endless-sky.github.io/blob/master/images/compass.svg as the base. License info at https://github.com/endless-sky/endless-sky/blob/master/copyright:

==========

Files: images/*

Copyright: Michael Zahniser [email protected]

License: CC-BY-SA-4.0

==========

When sharing, please make sure to include the information in this description including information regarding the stock image. If not possible, then at leas keep the metadata in the file, which contains similar information.

Modelled and animated in Blender on Linux

---

If you are affiliated to the game "Endless Sky" and need a change in licensing info let me know here.

cross-posted from: https://programming.dev/post/34025065

DeviantArt Link

Endless Sky is and open source game. This animation is inspired by the compass image that shows up on the menu screen.

CC BY-NC-SA 4.0 : https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en

Used stock https://github.com/endless-sky/endless-sky.github.io/blob/master/images/compass.svg as the base. License info at https://github.com/endless-sky/endless-sky/blob/master/copyright:

==========

Files: images/*

Copyright: Michael Zahniser [email protected]

License: CC-BY-SA-4.0

==========

When sharing, please make sure to include the information in this description including information regarding the stock image. If not possible, then at leas keep the metadata in the file, which contains similar information.

Modelled and animated in Blender on Linux

---

If you are affiliated to the game "Endless Sky" and need a change in licensing info let me know here.

pacman -S endless-sky

DeviantArt Link

Endless Sky is and open source game. This animation is inspired by the compass image that shows up on the menu screen.

CC BY-NC-SA 4.0 : https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en

Used stock https://github.com/endless-sky/endless-sky.github.io/blob/master/images/compass.svg as the base. License info at https://github.com/endless-sky/endless-sky/blob/master/copyright:

==========

Files: images/*

Copyright: Michael Zahniser [email protected]

License: CC-BY-SA-4.0

==========

When sharing, please make sure to include the information in this description including information regarding the stock image. If not possible, then at leas keep the metadata in the file, which contains similar information.

Modelled and animated in Blender on Linux

If you are affiliated to the game "Endless Sky" and need a change in licensing info let me know here.

I come from EndeavourOS and when I installed Arch manually, I realised that I had to systemctl enable quite a few services. That included NetworkManager and sddm.

I was wondering if there exists some PostTransaction hook available that would prompt me about enabling a service/socket after a package installs one?

So, if I were to do pacman -S extra/bluez-obex, it would later prompt me with:
Enable obex.service? [g|global] [u|user] [n|no]
And if I were to answer with anything other than "no"...
Start now?

Might be different for system services, but you get the point.

What is the rationale behind GPU heatsink fin design?

So I have seen a few GPU heatsinks and I wonder why some of them are how they are.

GPU placement in Cabinet

The originally intended and most widely used placement for ATX cases at least, is installing right on the PCIe slot, which goes horizontally and with the air incoming from the front of the case.

Then we have the "vertical" placement using the riser cable, which changes the direction from which the GPU fans take in air, but keep the GPU front, in the same direction, again lining up with the incoming air from the front.

Finally the very rare vertical placement, which has the front of the GPU rotated towards the top of the case, making it not line up with an airflow incoming from the front.
This also makes the GPU's ports inaccessible the standard way, giving a reason to the rarity.

::: spoiler Some examples I found for this

:::

Here we see that the first 2 placements would make up most of the ATX PC builds with the third one being either for different case styles or for extensively customised builds.

Fins, fans and airflow

I would assume that having the air flow along the fins would be better than it crossing the fins at ⦜90°. And even if the air flow due to the case inlet is being ⟂ to the airflow from the GPU fans (in case of front incoming air flowing along the fins), it should still lead to overall increase in air pressure (hence, air density) between the fins.^[Source: Mental simulation] Considering that GPUs tend to have gaps in the IO shield to let the air go out the back, I would assume they (designers of the thermal dissipation solution) want air from the fins to go out the back, which would be better with fins parallel to front incoming air.

Inference and Doubt

From the above 2, it would make sense for most GPUs to have their heatsink fins going along their length instead of their width, right?

Then what's up with the ASRock lineup, with all cards other than the Passive model, the Creator cards (which have the front covered by the shroud anyway, so no incoming airflow) and the watercooled cards (which is not applicable) having the fins ⟂ to front air inlet?
And of course they are not the only one doing it that way.

Follow Up

While discussing in this thread, I realised another point (which I didn't state anywhere in the comments):

• While it is desirable to have higher air density, it is not desirable to have air increasing in density while in the inter-fin space. Because that would cause the heat released when changing density to be transferred to the fins.
• Another way to say that is, the air will get hotter, while increasing its density. So, how much this factor matters, will depend upon the initial temperature difference between the air and the fins and how long the dense air stays in the inter-fin space. Oh and also the composition of air.

Also, bought 2 of them, because the brain needed to fart out loud.

Not only are the fans much slower than what the sticker says (2000RPM), they also make more heat in the motor than they will ever dissipate. And of course, they just couldn't sell one without RGB.

Looked closely and even the axle is not centred.

On the other hand

Can someone help me do something fun with this that would make me feel less shitty about myself?

I have a Seagate Expansion Portable HDD, which I want to check the SMART status of^[Why? For FUN of course!]

I looked at a comment for a WD HDD, which made me look into man smartctl -> /--device after having the message from smartctl -a <dev/path> having:

Read Device Identity failed: scsi error unsupported field in scsi command

If this is a USB connected device, look at the various --device=TYPE variants

Now the manual lists many different possible device types and I am yet, unable to find the correct one. Any ideas would be appreciated.

I tried simply searching for "seagate" in man smartctl, but there was no match in the --device section.

I am currently trying to look for a way to get information on what USB to SATA adapter is being used (hopefully without having to open it up)

Some additional info:

lsusb -v ...

Bus 00* Device 00*: ID 0bc2:231a Seagate RSS LLC Expansion Portable
Negotiated speed: SuperSpeed (5Gbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x0bc2 Seagate RSS LLC
  idProduct          0x231a Expansion Portable
  bcdDevice            7.10
  iManufacturer           1 Seagate
  iProduct                2 Expansion
  iSerial                 3 NAA*****
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0079
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              896mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        MaxStreams             32
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               7
        MaxStreams             32
        Data-out pipe (0x04)
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000f0e
      BESL Link Power Management (LPM) Supported
    BESL value     3840 us 
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat          32 micro seconds
Device Status:     0x0000
  (Bus Powered)

Screen Recording of an application window: at the bottom of a widget, the cursor changes to a resize icon. Click+Dragging the portion reveals empty white space.

Description, because "alt text" can't show it well:

			{
				emit differentFiles (ckFile.absoluteFilePath(),
					otherFile.absoluteFilePath(),
					FileCompareWorker::FileComparisonParams{FileComparisonParams::FileNameMatch,
						(ckFile.size() > otherFile.size()) ? FileComparisonParams::File1IsLarger
							: FileComparisonParams::File2IsLarger});
			}

After Alignment

			{
				emit differentFiles (ckFile.absoluteFilePath(),
					otherFile.absoluteFilePath(),
					FileCompareWorker::FileComparisonParams{FileComparisonParams::FileNameMatch,
						(ckFile.size() > otherFile.size()) ? FileComparisonParams::File1IsLarger
														   : FileComparisonParams::File2IsLarger});
			}

To WiFi users.

Do you reduce your router's WiFi Transmit Power to the bare minimum as required by you?

• Do you just keep it at the default 100%
• Did you not know you could reduce it (until now)
• Are you not able to control "your" WiFi router because it's the ISP provided router and they didn't give you the password?
• Do you actually require the 100% !?

A person, on the Gnome Issue, suggested that terminals inhibit sleep when there is stuff running in them.

Continuing from that discussion, I am trying to understand, at which point it would be desirable to implement said inhibition - terminal emulator, the shell or the program itself

Additionally:

• We want to inhibit when running stuff like pacman, wget, cp or mv
• We don't want to inhibit when running stuff like htop, less, watch

Hopefully we can get better input to the discussion here.

I have been thinking of a controller like this, which would be pretty fun to use for space games.

The ellipsoid marked as "Hand Piece", is supposed to be braced to the frame with motion encoders and need to push back the Hand Piece to the 0 position in case the user stops adding force in any direction.

Additionally, the hand piece can also have 5 buttons, 2 placed for the thumb and 3 placed for the 3 longer fingers each, with the button for the middle finger being a scroll wheel.

This should make up for actions like, Primary and Secondary fire, Target lock and cruise control adjustment, hence freeing the second hand for controlling utilities on the keyboard, or eating snacks. Whichever you prefer.

I have a multiboot system. One of the installed OS's does not use the NVMe SSD installed on the motherboard at all.
At the time of taking the screenshot, all the SSD partitions are unmounted, so apart from detection, the SSD is mostly unused.

• I would like the temps to drop down to SYSTIN (≈35°C) levels.
• I know, it's right next to my GPU, but I am not doing anything GPU intensive, the GPU temps are ~37°C ^[apart from GPU memory, which is 48°C due to the awful AMD 7th gen Zero RPM, which has no workarounds on Linux]

For the unmounted and unused HDDs, I just use hdparm -Y, but there seems to be nothing in terms of that for the SSD. And even though I appreciate the additional heat in winters, this is going to be too expensive for me. I'd rather burn some cheap Nichrome than my data storage device.

I checked out a Debian forum thread and from that, I checked the following:

❯ sudo nvme get-feature /dev/nvme0 -f 2 -H
get-feature:0x02 (Power Management), Current value:0x00000004
        Workload Hint (WH): 0 - No Workload
        Power State   (PS): 4

Showing it is already in the lowest power state.

Update: I probably checked that at the wrong time before. Did so again after Sleep and realised the Power State was 0. So just need to make sure the Power State went back to 4 after wake.

I have no active cooling setup for the SSD from my side. This becomes relevant soon.

• Checking the SSD temps (using the same widget as in the image), the temperature on Sensor 2 starts out at ~40°C (after a normal reboot) and slowly increases to >50°C as shown at the start of the graph. Power State (PS) is still 4.

• Running KDE partitionmanager, which probably does some reading to check the partition information, at 50°C stage, causes a temperature drop, as shown in the image.

• Running KDE partitionmanager right after reboot, when the temperature is increasing very sloowly, seems to do nothing significant.

• Turns out that after a few minutes of System Standby, the SSD doesn't return to PS: 4, so I have the culprit.
• Running partitionmanager after that causes it to go back to PS: 4

So we have a solution! All I need to do is run partitionmanager on wake. nlol jk

Motherboard: MSI MAG X570S TORPEDO MAX (MS-7D54)
SSD: Samsung 980 512GB (correct firmware, bought long before the fakes started coming out)

Until he actually had to use it.

Took 2 hours of reading through examples just to deploy the site.
Turns out, it is hard to do even just the bash stuff when you can't see the container.