• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Another computer question...

Anybody know of a full-size wired keyboard with short-travel low-profile keys? I've decided I prefer them to the full-travel typists' keyboard.
 
Wow! Huge range: https://eu.perixx.com/collections/keyboards

What I need is a UK layout version of this (apparently only available in US or German), and a USB-C adapter:
eu.perixx.com

PERIBOARD-210 - Wired Standard Keyboard Scissor Keys

PERIBOARD-210: Wired keyboard with quiet scissor keys, comfort tilt, thin design, 1.5m plug-and-play cable, and wide USB compatibility.
eu.perixx.com eu.perixx.com

...except here it is on Amazon with a UK layout! https://www.amazon.co.uk/Perixx-PERIBOARD-210-Keyboard-Computer-Desktop/dp/B08QDV7CGX

The only thing wrong with it (apart from USB-C) is that it doesn't have the handy sleep and off buttons on my current Trend Trust, but I guess I can live with that (and the chance of finding one which has EVERYTHING is minuscule).

D8F7E723-776C-4DC6-BC44-C721F48E3EAD.jpeg
 
Last edited:
Adapter turned up yesterday, just in time for the last day of a big authoring job, and the Perixx 210 suits me fine (once I added a couple of rubber feet to increase the rake).
 
Black Hole said:
Adapter turned up yesterday, just in time for the last day of a big authoring job, and the Perixx 210 suits me fine (once I added a couple of rubber feet to increase the rake).
Click to expand...
...and once I was certain: I cut off the USB-C, shortened the cable (it only has to go to the KVM switch), and fitted a conventional USB plug. Still very happy with it.

Although it lacks a key to put the PC to sleep, it is possible to change the default power action on the Windows menu from "shut down" to "sleep".

Just to keep up the ZEN blog, I posted about 3D-printing a panel mount for a Molex HDD power socket to provide external power alongside the eSATA port HERE.
 
Black Hole said:
Brilliant. That worked, many thanks for the clarifications. I've called it devcon64.exe, to be explicit.

In case anybody needs a summary:

How to add command line control over stuff normally done through Device Manager in Windows
  1. Download the relevant .cab file from https://superuser.com/questions/1002950/quick-method-to-install-devcon-exe. I'm using 64-bit Win7, which requires the "amd64" version (apparently) rather than the "x86" version, regardless that I have an Intel processor (if using 32-bit Windows, you need the "x86" version). The "Windows 10 version 1809" revision worked for me, despite me running Win7.

  2. Drill into the .cab file (it's like a zip) and extract the file listed on the web page - in the case of Win10 v1809 for amd64, that's file filbad6e2cce5ebc45a401e19c613d0a28f from 787bee96dbd26371076b37b13c405890.cab, and rename it devcon.exe (or whatever you like).

  3. I then put it into C:\Windows\system32 (requires admin access to do this), where it is on the default command search path, but you could put it anywhere if you use an explicit path when calling.

  4. From the Start menu, search "cmd" and right-click the search result "cmd.exe", select "Run as Administrator". This produces a command console running at Admin privilege. The command "devcon help" provides a command list, and "devcon help <command>" provides more details.
Click to expand...
I've hit another wrinkle with my notebook-on-external-screen setup: HDMI sound. After a wake-up, the Sound dialogue I get when I right-click the "speaker" icon in the notification area and select "Playback devices" shows "HDMI Device" as default and audio activity on the level meter, but no sound comes out of the display until I make a different device the default and then make the HDMI default again... then it works fine until I put the system to sleep.

At least the work-around is easy, but any clues how to automate it would be appreciated.
 
I've been looking at the installation/upgrade notes for Linux Mint 20.2, and they're making an issue about merging /bin and /usr/bin, etc. Apparently Linuxes in general are moving away from that separation, and it has been a mystery and point of confusion (to me at least) why they are there.

Well, reading up the background, it seems to be simply that the origins of Unix was when disk packs were very small, and when they ran out of space on the first drive they had to start putting stuff not critical to the initial boot on the next (/usr) drive (and then when that was full too, the /home drive)!

Apparently, everything will now be in /usr/bin (etc), with symlinks from /bin to /usr/bin (etc), so it will no longer matter where some script thinks an executable should be – all roads lead to Rome (or /usr/bin), which (apparently) will make the different Linux distributions rather more compatible with each other than they have been (making porting much easier).

Why that way around and not put everything in /bin (as per the original Unix) is something else to get my head around.
 
Last edited:
Black Hole said:
Why that way around and not put everything in /bin (as per the original Unix) is something else to get my head around.
Click to expand...
I’m no Unix/Linux expert - but I’m with you on this one. I prefer things to be where they’ve always been and to link new nomenclature to old places. But does it matter? No. So long as the links are in place and not circular - no problem.
 
Black Hole said:
I've been looking at the installation/upgrade notes for Linux Mint 20.2, and they're making an issue about merging /bin and /usr/bin, etc.
Click to expand...
That rings a bell from either 20.1 or 20.0 - I saw an Update Manager update this morning, but haven't looked further - so it's not entirely new. It was no hassle anyway.
Why that way around and not put everything in /bin
Click to expand...
Dunno. It would make sense (to me) to put things in the shorter path, as there is less to type when you have to, but otherwise it makes diddly squat difference as everything is on the PATH anyway (although /usr/bin usually comes before /bin).
 
It's amazing how much has been inherited over decades when the technical reasons are no longer applicable (and haven't been for decades). I suppose people are loath to fix what ain't broken, even for simplification.
 
Yes, although the order of the PATH could be swapped round instead, but that probably breaks some other assumption I'm unaware of!
 
I've been piddling around with Linux Mint trying to clone a HD-FOX HDD to SSD, mainly because of the compatible file systems, but my Win7 notebook is running incredibly slowly in the current heat so I'm gravitating to my Linux tower anyway (when I can't use the iPad for whatever it is!).

Of particular aggravation (in Nemo, the Linux Mint Cinnamon file manager):
  • Having to explicitly open a drive as root before being permitted to write to it (because apparently I'm not the owner!), which means drilling down to where it is mounted in the file system because right-clicking the navigation shortcut doesn't offer "open as root";

  • Ctrl+A (select all) and then drag'n'drop copy does not include hidden files (file name beginning with "."), even though Nemo is set to show hidden files (but they do copy if explicitly drag'n'dropped);

  • I really don't understand this: Nemo shows the [Modsettings] folder as having no contents (not even subfolders)... and yet the contents did copy.
I also find the copy text from a webshell session in Firefox doesn't work.
 
A little bash help please:

I want to bulk-process a load of files (using Mint). If I were using DOS* it would be something like:
Code: 
for %%1 in <wildcard file selection> do <process_name> %%1 > %%1.out
I grant that is a little dirty, ".out" simply gets appended to whatever filename it is in the loop instance (eg input = "test.txt", output = "test.txt.out"), but that can be cleaned up later and I know of no means around it on the DOS command line.

My question is: how to do that in bash?


* Yes, I know it's not "DOS"... don't start!
 
There are always loads of gotchas (I find anyway), but something like this:
for f in *.txt; do bash -c "cat \"$f\" >\"$f.out\""; done

Redirection is tricky even under "DOS" (who, moi?) unless you intend to write everything to one file.
There are loads of %whatevers you can do these days to stop you making the mess in the first place. Just look'em up.
 
You must log in or register to reply here.
Back
Top