GNOME has a long standing UX issue regarding choosing the audio output device when multiple audio devices (usually PulseAudio ALSA sinks) are available. In the default GNOME desktop (until v43) the user needs to navigate all the way to Settings->Sound and fiddle with drop-down dialogues to make this choice.
Some options to make this more convenient are available.
GNOME 43 adds a new Quick Settings feature which allows, amongst others, the audio device to be chosen directly from the “top bar”‘s “system menu” UI in the upper right corner.
The exact appearance and features exposed in the Quick Settings can be modified by installing the “Quick Setting Tweaker” GNOME Shell extension (GPL-3.0/MIT license).
GNOME 43 is present in Debian based distributions since Debian 12 (bookwoorm, 2023-07) & Ubuntu 23.04 (lunar). Note that after v3.38 a new GNOME versioning scheme was introduced meaning that the following release became v40.
The Volume Mixer GNOME Shell extension (GPL-2.0 license) makes the sound output selection available from the top bar’s system menu in a nice an uncluttered way, hiding unnecessary distractions (fx. no input selection when no application is recording).
Similarly the Sound Input & Output Device Chooser GNOME Shell extension (GPL-3.0 license) also makes the selection available in the system menu. However, the UI is slightly more convoluted with the width of the dialogue expanding dynamically making the UX a bit unintuitive and jumpy.
If you use multiple desktops or just prefer a non-GNOME specific solution another way is to install the Ubuntu AppIndicator compatible “Sound Switcher Indicator” (GPL-3.0 license) in combination with the GNOME Shell extension “AppIndicator and KStatusNotifierItem Support” (GPL-2.0 license), which will make Ubuntu AppIndicators appear as tray icons in the GNOME top bar.
The support and non-support of tray icons, requiring the use of extensions like the above, has been a long standing discussion in the GNOME community since the GNOME3 redesign work decided that no existing systray/indicator/status icon protocol was adequate for the GNOME UI requirement.
Curiously the Ubuntu AppIndicator standard is a remnant of Canonical’s attempted desktop/mobile convergence environment Ubuntu Unity (distributed in parallel on mobile OS Ubuntu Touch and standard Ubuntu desksop). This has now been abandoned by Canonical/Ubuntu but still lives somewhat on in the community; see ubuntu-touch.io & ubuntuunity.org.
EDIT 2023-09-20: add screenshots minor text corrections
A May 24th 2023 change of GitHub’s RSA SSH host key just hit me on an older, less used, system doing a git clone. The change was prompted by an unintended exposure of the private part of the host key by GitHub itself.
GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository Github blog-post, “We updated our RSA SSH host key”, 2023-03-23
GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository
I’m getting even more reluctant to trust a large organization where such a thing can happen. Additionally they didn’t communicate about this in a way that caught my attention. And now that it has my attention, they do not want to share the specifics about the incident to enable assessment of impact (like exposure duration, popularity of repository etc).
Below is the manual recovery with explanations of what happens and why. I don’t like the way the official blog-post instructs users to retrieving the validated host key in a non-visible way, without human eye balls doing the validation. This is the only chance in the process for injecting human trust into the validation of the host key, don’t skip it!
Consequence #1: fatal MitM warningWhen an SSH server’s host key is different to a connecting client (system) compared to what the system has previously seen and acknowledged by the user to be a valid key from the intended counterpart (you do check those host key fingerprint strings, right? If not; PHComp help, WinSCP help), it obviously should and do warn the user about this. Whether the change is of malicious origin or not, is up to the user to investigate. So with OpenSSH this happens;
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s. Please contact your system administrator. Add correct host key in <~>/.ssh/known_hosts to get rid of this message. Offending RSA key in <~>/.ssh/known_hosts:17 remove with: ssh-keygen -f "<~>/.ssh/known_hosts" -R "github.com" RSA host key for github.com has changed and you have requested strict checking. Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $
Remedy #1: remove known host keys for domain (pr. OpenSSH instruction)Remove host keys associated with github.com domain using -R option to ssh-keygen (default for -f is the UserKnownHostsFile config keyword with default ~/.ssh/known_hosts, so no need to specify that):
$ ssh-keygen -R github.com# Host github.com found: line 17# Host github.com found: line 18# Host github.com found: line 19<~>/.ssh/known_hosts updated.Original contents retained as <~>/.ssh/known_hosts.old$Consequence #2: non-fatal domain and IP mismatchNow, because host key references are cached for both the domain and IP there are still mismatches caused by the key exchange choosing ECDSA host key and the key associated with the IP address is the old RSA key. This is prompted during each connection attempt:
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.121.3' Offending key for IP in <~>/.ssh/known_hosts:63 Matching host key in <~>/.ssh/known_hosts:72 Are you sure you want to continue connecting (yes/no)? yes remote: Enumerating objects: 153255, done. remote: Counting objects: 100% (177/177), done. remote: Compressing objects: 100% (103/103), done. remote: Total 153255 (delta 103), reused 121 (delta 74), pack-reused 153078 Receiving objects: 100% (153255/153255), 550.17 MiB | 2.39 MiB/s, done. Resolving deltas: 100% (111423/111423), done. $
Remedy #2: remove known host keys for IPsTo get rid of the mismatch warning, the known host keys associated with IP addresses needs to be removed also. Potentially any of the listed endpoint IP addresses used with an RSA host key on the system earlier will now conflict with the ECDSA from server, requiring removal:
$ ssh-keygen -R 140.82.121.3 # Host 140.82.121.3 found: line 63 <~>/.ssh/known_hosts updated. Original contents retained as <~>/.ssh/known_hosts.old $ $ ssh-keygen -R 140.82.121.4 # Host 140.82.121.4 found: line 161 <~>/.ssh/known_hosts updated. Original contents retained as <~>/.ssh/known_hosts.old $ After remedy Now, the SSH client will see an unknown host key and prompt for validation. Be sure to verify the presented host key with the officially communicated one (from doc. article or API):
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... The authenticity of host 'github.com (140.82.121.4)' can't be established. ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'github.com,140.82.121.4' (ECDSA) to the list of known hosts. remote: Enumerating objects: 153152, done. remote: Counting objects: 100% (183/183), done. remote: Compressing objects: 100% (83/83), done. Receiving objects: 100% (153152/153152), 550.22 MiB | 1.42 MiB/s, done. remote: Total 153152 (delta 109), reused 158 (delta 100), pack-reused 152969 Resolving deltas: 100% (111352/111352), done. $
While once again being annoyed by the obnoxious way modern GNOME handles in-application dialogues (fx. Nautilus’ Properties dialog) as modal (ie. freezes the parent window) AND even prevents movement of the dialogue relative to the parent I did some searching which revealed a partly solution!
This was also complained about in a 2017 LibreOffice bug report which concluded that the immobility is a GNOME 3 desktop default behaviour caused by the setting attach-modal-dialogs.
Details in the related GNOME bug report shows how to disable this by modifying gsettings;
In a regular upstream GNOME session, `gsettings set org.gnome.shell.overrides attach-modal-dialogs false`, a schema of ‘org.gnome.shell.extensions.classic-overrides’ for the classic session and afaik ‘org.gnome.mutter’ for a Ubuntu-patched GNOME.
Now knowing which term to search for, lots of discussion about this shows up (including posts similar to this), the best write up of the mitigation is probably this askubuntu question. And the mother opinionated Ubuntu bug report is this where Ubuntu officially states;
We do not consider Gnome’s defaults in this area unreasonable.
But the reason for this behaviour? Seems to be unknown as even this 2018 bug report on gnome-shell hasn’t received any official answer or comment about why this would be a sane default. Go figure…
TLDR;On Ubuntu 20.04 and similar distributions turn off GNOME’s attach-modal-dialogs feature by doing;
$ gsettings set org.gnome.mutter attach-modal-dialogs false
Or if you like the mouse; install & launch gnome–tweaks and click “Windows” -> “Attach Modal Dialogues”;
Oh, and remember to read the Nielsen Norman Group article “Modal & Nonmodal Dialogs: When (& When Not) to Use Them” (summary: Modal dialogs interrupt users and demand an action. They are appropriate when user’s attention needs to be directed toward important information).
Edit:2023-07-30: add gnome-tweaks approach
If you end up in a situation where your PHP installation gets ahead of your application (like fx. if your hosting provider deprecates PHP 7.4 without you having had the opportunity to update your WordPress 4.9.22 blog), here is a small tip if this results in errors related to the, in PHP 8 removed, function get_magic_quotes_gpc() (see PHP RFC from 2018 about this decision).
As this function has been a dummy function returning false since PHP 5.4 (see php-src commit removing the functionality) and emitting a deprecation warning since PHP 7.4 (see php-src commit deprecating function) in almost any case perceivable you would be able to fake this function and satisfy your application’s need for it to exist.
To fix this for WordPress add the following line to the wp-includes/load.php file (fx. at line 7 for v4.9.22);
function get_magic_quotes_gpc() {return false;}
And voila! WordPress will be functional again (please consider using the chance to upgrade).
Unless, of course, there are other problems related to the PHP upgrade…
This could fx. be ancient themes (like Ahimsa) that use deprecated associative array notation (unquoted string literal indexes). These needs fixing first by adding quotes to all of the indexing strings in sub-arrays of the $skin_fields array, like below;
$skin_fields = array ( array ( "name" => "skinpagebgtopbg", "desc" => "Page Background Top", "csssel" => "#bgtop", "attr" => "background-color" ), array ( "name" => "skinpagediv", "desc" => "Page Background Divider Colour", "csssel" => "#bgtop", "attr" => "border-bottom-color" ), array ( "name" => "skinpagebgbotbg", "desc" => "Page Background Bottom", "csssel" => "BODY", "attr" => "background-color" ), array ( "name" => "skinhyperlinks", "desc" => "Hyperlinks", "csssel" => "A", "attr" => "color" ), array ( "name" => "skincapsulebg", "desc" => "Default Bubble Background", "csssel" => ".capsule", "attr" => "background-color" ), array ( "name" => "skincapsulefg", "desc" => "Default Bubble Text Colour", "csssel" => ".capsule", "attr" => "color" ), array ( "name" => "skinheaderbg", "desc" => "Header Background", "csssel" => "#header", "attr" => "background-color" ), array ( "name" => "skinheaderfg", "desc" => "Header Text Colour", "csssel" => "#header, #header table, #header a", "attr" => "color" ), array ( "name" => "skinheadersepcolour", "desc" => "Colour of Separator Bar in Header", "csssel" => "#title", "attr" => "border-right-color" ), array ( "name" => "skinsidebarbg", "desc" => "Sidebar Background", "csssel" => ".sidebar, .tdsidebar", "attr" => "background-color" ), array ( "name" => "skinsbwidgetbg", "desc" => "Sidebar Widgets Background", "csssel" => ".sidebarlist", "attr" => "background-color" ), array ( "name" => "skinsbwidgetfg", "desc" => "Sidebar Widgets Text Colour", "csssel" => ".sidebarlist", "attr" => "color" ), array ( "name" => "skinsblegendbg", "desc" => "Sidebar Widget Title Background", "csssel" => ".sidebarlist > legend", "attr" => "background-color" ), array ( "name" => "skinsblegendfg", "desc" => "Sidebar Widget Title Text Colour", "csssel" => ".sidebarlist > legend", "attr" => "color" ), array ( "name" => "skinsblistdiv", "desc" => "Sidebar/Action Lists Divider Colour", "csssel" => ".sidebarlist li, #postaction li", "attr" => "border-top-color" ), array ( "name" => "skinsblink", "desc" => "Sidebar Widget Hyperlinks", "csssel" => ".sidebarlist a", "attr" => "color" ), array ( "name" => "skincalcaption", "desc" => "Sidebar Calendar Caption Colour", "csssel" => "#wp-calendar caption", "attr" => "color" ), array ( "name" => "skincalheaderbg", "desc" => "Sidebar Calendar Column Header Background", "csssel" => "#wp-calendar thead th, #wp-calendar tfoot td.pad", "attr" => "background-color" ), array ( "name" => "skincalheaderfg", "desc" => "Sidebar Calendar Column Header Text Colour", "csssel" => "#wp-calendar thead th", "attr" => "color" ), array ( "name" => "skincalcellfg", "desc" => "Sidebar Calendar Entries Text Colour", "csssel" => "#wp-calendar tbody td", "attr" => "color" ), array ( "name" => "skincalnpbg", "desc" => "Sidebar Calendar Next/Prev Links Background", "csssel" => "#wp-calendar #next, #wp-calendar #prev", "attr" => "background-color" ), array ( "name" => "skincalnpfg", "desc" => "Sidebar Calendar Next/Prev Links Text Colour", "csssel" => "#wp-calendar #next, #wp-calendar #prev, #wp-calendar tfoot a", "attr" => "color" ), array ( "name" => "skintextwdgtfg", "desc" => "Sidebar Text Widget Text Colour", "csssel" => ".textwidget", "attr" => "color" ), array ( "name" => "skincontentbg", "desc" => "Main Content Background", "csssel" => "#content", "attr" => "background-color" ), array ( "name" => "skinpostpagebg", "desc" => "Post or Page Entry Background", "csssel" => ".post > fieldset", "attr" => "background-color" ), array ( "name" => "skinpostpagefg", "desc" => "Post or Page Entry Text Colour", "csssel" => ".entry", "attr" => "color" ), array ( "name" => "skinpptitlebg", "desc" => "Post, Page, Comments Title Background", "csssel" => ".post .title, #comments > legend, .comment > legend, #responsebox > legend", "attr" => "background-color" ), array ( "name" => "skinpptitlefg", "desc" => "Post, Page, Comments Title Text Colour", "csssel" => ".post .title, .post .title a, " . "#comments > legend, .comment > legend, #responsebox > legend", "attr" => "color" ), array ( "name" => "skinmetabarbg", "desc" => "Post/Page/Comment Bottom Bar Background", "csssel" => ".postmetadata", "attr" => "background-color" ), array ( "name" => "skincattagbg", "desc" => "Category/Tag Lists Background", "csssel" => ".postcattags", "attr" => "background-color" ), array ( "name" => "skincattagfg", "desc" => "Category/Tag Lists Text/Link Colour", "csssel" => ".postcattags, .postcattags a", "attr" => "color" ), array ( "name" => "skin1cattagbubblebg", "desc" => "Single Post Cat/Tag Bubble Background", "csssel" => "#single .postcattags .capsule", "attr" => "background-color" ), array ( "name" => "skin1cattagbubblefg", "desc" => "Single Post Cat/Tag Bubble Text/Link Colour", "csssel" => "#single .postcattags .capsule, #single .postcattags .capsule a", "attr" => "color" ), array ( "name" => "skinbqbg", "desc" => "Blockquote Background", "csssel" => "blockquote", "attr" => "background-color" ), array ( "name" => "skinbqfg", "desc" => "Blockquote Text Colour", "csssel" => "blockquote", "attr" => "color" ), array ( "name" => "skinlistbg", "desc" => "Page/Post Ordered/Unordered List Background", "csssel" => ".entry UL, .entry OL", "attr" => "background-color" ), array ( "name" => "skinlistfg", "desc" => "Page/Post Ordered/Unordered Text Colour", "csssel" => ".entry UL, .entry OL", "attr" => "color" ), array ( "name" => "skinpost1stletterfg", "desc" => "Post First Letter Colour", "csssel" => ".entry > P:first-child:first-letter", "attr" => "color" ), array ( "name" => "skinactionbg", "desc" => "Action Bubbles (Edit, Reply, etc) Background", "csssel" => ".actbubble", "attr" => "background-color" ), array ( "name" => "skinactionfg", "desc" => "Action Bubbles (Edit, Reply, etc) Text Colour", "csssel" => ".actbubble, .actbubble a", "attr" => "color" ), array ( "name" => "skincommentsbg", "desc" => "Comments Block Background", "csssel" => "#comments", "attr" => "background-color" ), array ( "name" => "skincommentbg", "desc" => "Comment Background", "csssel" => "fieldset.comment, fieldset.comment .commenttext", "attr" => "background-color" ), array ( "name" => "skincommentfg", "desc" => "Comment Text Colour", "csssel" => "fieldset.comment .commenttext", "attr" => "color" ), array ( "name" => "skinresponsebg", "desc" => "Response Box Background", "csssel" => "#responsebox", "attr" => "background-color" ) );
So, recession is here making local and global companies alike feel the heat. Changes in consumer behaviour affects especially the global tech companies very quickly because of the way they have almost completely gobbled up all marketing spending of every seller and reseller with any digital outlet presence.
As the digital advertising chain is decoupled from anything physical this ripples from consumer spending to impacting big tech revenue with immense speed. This, of course will affect how these companies use their resources, and the workforce needed to run their businesses.
To try to quantify what is happening to global tech companies’ workforce, I’ve collected some numbers and below is a chart illustrating the announced lay-offs in nine prominent big tech companies as of 2023-01-20. On this day, Google announced their reduction of 12’000 “roles” which triggered me to look into this.
Note some trends;
Download spread sheet in ODS format
So, uberspace.de (which hosts this site at the time of writing) announced timely on 2022-10-27 that instances (aka. asteroids) using PHP 7.4 will automatically upgrade to PHP 8.0 on 2022-11-29 due to 7.4 going out of active support on 2022-11-28;
Ahoy, You have selected PHP 7.4 as the active version on your Asteroid. Support for this version will end on November 28, 2022. For your and our security we will upgrade your account to PHP 8.0 on November 29, 2022. Usually you will not notice anything and there is nothing else to do, because most tools and programs like WordPress and Nextcloud have been working with PHP 8.0 for a long time. If you want to be on the safe side, please check in advance if your tools are up to date. By the way: You can also set your PHP version yourself. You can find all the information you need about PHP in our manual: https://manual.uberspace.de/lang-php/#change-version For questions and feedback please contact our support team: https://uberspace.de/support/ Best regards Boni, Janto, Kim, Leah, luto, Moritz, Nati, Nico, Noah, Pelzi, Mo, Sabrina & Jonas
Ahoy,
You have selected PHP 7.4 as the active version on your Asteroid. Support for this version will end on November 28, 2022. For your and our security we will upgrade your account to PHP 8.0 on November 29, 2022.
Usually you will not notice anything and there is nothing else to do, because most tools and programs like WordPress and Nextcloud have been working with PHP 8.0 for a long time. If you want to be on the safe side, please check in advance if your tools are up to date.
By the way: You can also set your PHP version yourself. You can find all the information you need about PHP in our manual: https://manual.uberspace.de/lang-php/#change-version
For questions and feedback please contact our support team: https://uberspace.de/support/
Best regards Boni, Janto, Kim, Leah, luto, Moritz, Nati, Nico, Noah, Pelzi, Mo, Sabrina & Jonas
This went under my radar on migration day, and due to the site still being operational I did not think it caused any issues.
However, on 2023-01-09 the site suddenly went offline and investigating logs, PHP errors were thrown in one of the main WordPress includes;
[09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “[09-Jan-2023 18:41:58 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in <redacted>/wp-includes/load.php:651” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “Stack trace:” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “#0 <redacted>/wp-settings.php(333): wp_magic_quotes()” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “#1 <redacted>/wp-config.php(39): require_once(‘<redacted>’)” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “#2 <redacted>/wp-load.php(37): require_once(‘<redacted>’)” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “#3 <redacted>/xmlrpc.php(29): include(‘<redacted>/’)” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: “#4 {main}” [09-Jan-2023 19:41:58] WARNING: [pool www] child 19454 said into stderr: ” thrown in <redacted>/wp-includes/load.php on line 651″
This is due to the PHP function get_magic_quotes_gpc(), which is already deprecated in 7.4, being completely removed in 8.0. However in WordPress before 5.3 (released 2019-11-12, see announcement or further details) this function is assumed to be present. The location throwing above is the first location in the code path hitting the use of this;
The quick fix to this was downgrading PHP by following the guide mentioned above, which was surprinsingly possible. However, this should only be regarded as a temporary solution as PHP out of security support is not a good solution. As the guide does not mention when PHP 7.4 is going out of support and being completely removed from uberspace, I tried pinging their support in their fediverse account, no resposnse as of ending this write-up.
This post is a rescue mission for a quite old comment I’ve made on the Danish computer science publication version2.dk. As the publication is beginning to put up pay-walls around their articles I’ll repost comments here to keep my own writing out in the open.
It is a comment to an article detailing how the Danish telecom company TDC (previous state driven monopoly Tele Danmark) fails to adhere to the GPL license when distributing a network device built on the GNU/Linux distribution OpenWRT containing large amounts of GPL licensed software.
Link to original comment: version2.dk/artikel/tdc-vi-har-dummet-os-med-open-source-licens-140230#comment-304571
Reproduction of original Danish text:
15. april 2015 kl. 12:05 “..som GPL V2 ellers lægger op til..” Kan ikke lade være med at finde det påfaldende at man er så skrigende subjektiv i rapporteringen når man forholder sig til brud på copyright. Virksomhedernes holdning skinner selvfølgelig igennem, men en neutral presse burde rapportere mere objektivt end dette. Den selvsamme forseelse ville man formentlig kalde pirateri og opfatte som vækst/samfunds/forretnings-undergravende, hvis det drejede sig om systematisk copyright-brud på proprietær software som et specifikt og veldefineret firma tjener penge på. Men fordi dette er fri software(/open source), som kun har potentiale til at komme hele menneskeheden til gode, så opfattes licensen som noget der er “lagt op til”. Det er jo hovedrystende forudindtaget. Bestemmelserne i GPL er selvfølgelig lige så gyldige som ethvert andet sæt betingelser en ophavsretsindehaver kunne finde på at videredistribuere sit værk under. Angående sagens substans er betingelserne i GPL v2 klare og veldefinerede og har været det siden 1991. Det kommer ikke bag på nogen der har fingrene i sovsen, heller ikke sagem/sagemcom som har været med længe, at brugeren skal gøres opmærksom på at et produkt indeholder GPL-software, og at kildekoden der anvendes i produktet skal gøres tilgængelig for brugeren. Alt andet er klaphatteri og klamp, usympatisk, undergravende og uden respekt for det arbejde der profiteres af ved at anvende fri software som grundlag for sin kommercielle eksistens. Man må følge reglerne eller lade være med at lege med hvis man ikke er i stand til at sætte sig ind i dem, det forlanger virksomhederne også selv af deres kunder. Godt at se at der er velvilje fra TDC, det burde bare have foregået på forkant i stedet for bagkant. Håber dog de får fat i nogle mere kompetente mennesker at spørge end dem der har svaret “Boksen kører BUSYBOX Linux”, ellers er det op ad bakke. Mikkel
“..som GPL V2 ellers lægger op til..”
Kan ikke lade være med at finde det påfaldende at man er så skrigende subjektiv i rapporteringen når man forholder sig til brud på copyright. Virksomhedernes holdning skinner selvfølgelig igennem, men en neutral presse burde rapportere mere objektivt end dette.
Den selvsamme forseelse ville man formentlig kalde pirateri og opfatte som vækst/samfunds/forretnings-undergravende, hvis det drejede sig om systematisk copyright-brud på proprietær software som et specifikt og veldefineret firma tjener penge på. Men fordi dette er fri software(/open source), som kun har potentiale til at komme hele menneskeheden til gode, så opfattes licensen som noget der er “lagt op til”. Det er jo hovedrystende forudindtaget. Bestemmelserne i GPL er selvfølgelig lige så gyldige som ethvert andet sæt betingelser en ophavsretsindehaver kunne finde på at videredistribuere sit værk under.
Angående sagens substans er betingelserne i GPL v2 klare og veldefinerede og har været det siden 1991. Det kommer ikke bag på nogen der har fingrene i sovsen, heller ikke sagem/sagemcom som har været med længe, at brugeren skal gøres opmærksom på at et produkt indeholder GPL-software, og at kildekoden der anvendes i produktet skal gøres tilgængelig for brugeren.
Alt andet er klaphatteri og klamp, usympatisk, undergravende og uden respekt for det arbejde der profiteres af ved at anvende fri software som grundlag for sin kommercielle eksistens. Man må følge reglerne eller lade være med at lege med hvis man ikke er i stand til at sætte sig ind i dem, det forlanger virksomhederne også selv af deres kunder.
Godt at se at der er velvilje fra TDC, det burde bare have foregået på forkant i stedet for bagkant. Håber dog de får fat i nogle mere kompetente mennesker at spørge end dem der har svaret “Boksen kører BUSYBOX Linux”, ellers er det op ad bakke.
Mikkel
EDIT 2021-08-31: add section about possible unexpected change of behaviour when using the simple (global) setup (fx. git)
There is this nifty OS project, GNU, which has this nifty piece of software for syntax highlighting, source-highlight (aka. src-highlite), together with which is distributed this nifty shell script, src-hilite-lesspipe.sh, meant for piping arbitrary text through the highlighter selecting and applying a sensible highlight language definition, before being paged in some nifty pager which is able to interpret ANSI escape codes (ISO/IEC 6429 or ECMA-48, previously ANSI X3.64/FIPS PUB 86) like fx. the nifty and ubiquitous less.
Sadly, even after having installed less and source-highlight on modern Ubuntu and Debian systems they are not inter-operating by default. You’d have to feel the itch of syntax highlighting, discover source-highlight and dig its documentation to find out about said script.
Below is a quick two-line shell HOW-TO which sets up environment variables for the current user to enable auto-detection of language and subsequent syntax highlighting pr. default in less using GNU source-highlight (here done on Ubuntu 20.04 LTS, should behave similarly on Debian and derived distributions);
$ sudo apt install source-highlight $ echo -e "\nexport LESSOPEN=\"| /usr/share/source-highlight/src-hilite-lesspipe.sh %s\"\nexport LESS=' -R '" >> ~/.bash_aliases
This setup will make fx. some C source code display as below in less.
environment set up for less to enable ANSI color codes and pass any text through source-highlighter for potential ANSI escape code addition
less showing highlighted C code, auto-detected and highlighted by GNU source-highlighter
One caveat of this global setup being active for any invocation of less, is that most programs will behave accordingly and some maybe different from expectations.
Notably, using the git command line client with the above setup will make git refrain from setting a default LESS=FRX environment (see core.pager of man git config) when invoking less. This turns off the less features “quit-if-one-screen” (F) and “no-init” (X) (see OPTIONS of man less) which usually makes less invisible in git contexts unless paging is actually needed. This could cause confusion for some, making git seemingly take over the terminal on even 1 line outputs (see this bug report on GNU src-hilite and my comment detailing the above).
One solution to this would of course be to add “FX” to the environment, another is making a little more elaborate, more conservative and less transparent setup, as below.
If you’d still like to have a “plain less” not messing with and amending you text unless you ask it to, you could make an alias to use specifically when you want syntax highlighting. Put these somewhere interpreted by you shell (for bash fx. ~/.bash_aliases);
# syntax highlight in less alias lesssh="LESSOPEN='|/usr/share/source-highlight/src-hilite-lesspipe.sh %s' LESS=' -R ' less" function lessurl() { wget -O- -q $1 |source-highlight -f esc -s html |less -R; }
Line two is a bonus shell function pulling some HTML from a webserver using wget, adding syntax highlighting and showing it in less.
For the brave, take a tour of the “info source-highlight” (or “man source-highlight”) manuals (also here) to become familiar with the tool. You can use it anywhere you’d like some colour on arbitrary text and where color are supported in various ways and encodings, for example HTML and latex;
source-highlight adding color encoding to C code using HTML and latex encoding
If you are a programmer wanting to add highlighting features to you own application, the command line utilities are building on a highlighting library which you can utilise (API documentation here).
Et lidt underligt spørgsmål måske, men er der nogen der har gjort sig erfaringer med Micro:bit i frostvejr – Er den stabil, og kan den starte op i f.eks. -20 grader ? Jeg har googlet – men søgeresultatet på de relevante søgning er temmelig forurenet af at der jo er en indbygget temperatursensor…
Ja, det ser da lidt underligt ud. Der er ikke opgivet nogen driftstemperatur (“oprarating temperature”) eller for så vidt opbevaringstemperatur (“storage temperature”) i specifikationerne for hverken V1.5 (https://tech.microbit.org/hardware/1-5-revision/) eller V2 (https://tech.microbit.org/hardware/). En søgning i dokumentationens git-arkiv bekræfter at der kun nævnes noget om temperaturer når den indbyggede sensor i nRF-SoC’en omtales (https://github.com/microbit-foundation/dev-docs/search?q=temperature+&type=). Ligeledes bruges ordet “operating” kun om spænding, strøm og system (=OS) (https://github.com/microbit-foundation/dev-docs/search?q=operating&type=). Så den oplysning er Micro:bit Foundation åbenbart ikke særligt vilde med at dele, hvilket tyder på at det ikke har været en prioritet under design og produktion (hvilket er forståeligt nok for et ikke-industrielt stykke undervisningsmateriale). Så du skal nok under alle omstændigheder ikke forvente en konsistent oplevelse. Hvis man skulle give et kvalificeret bud, kunne man kigger på hovedkomponenternes specificerede driftstemperaturer, hvilket i hvert fald siger noget om de øvre og nedre grænser, men komponenternes komplekse interaktioner med hinanden (mekanisk, termisk, elektrisk) i det færdige produkt har selvfølgelig betydning for de endelige grænser. V1.5: nRF51822 (primær SoC): -25 – 75 grader C (http://infocenter.nordicsemi.com/pdf/nRF51822_PS_v3.1.pdf#page=38) KL26 (USB-interfacechip): -40 – 105 grader C: (http://www.nxp.com/docs/pcn_attachments/16440_KL26P64M48SF5_Rev.4.pdf) V2: nRF52833 (primær SoC): -40 – 85 grader C (kan gå op til 105 grader C under specielle betingelser) (https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf#page=608) KL27 (USB-interfacechip): -40 – 105 grader C (https://www.nxp.com/docs/en/data-sheet/KL27P64M48SF6.pdf) Det giver da et fingerpeg, god fornøjelse med fryseren ;).
I took the chance on a summer day last year, 2019-06-20, to take a peek at the construction site of the Norwegian Bulk Infrastructure data center DK01 Campus being built in Kjersing, Esbjerg, Denmark. The pictures were stowed away until now but I think they deserve to be set free, so here goes.
The data center is a part of Bulk Infrastructure’s involvement in the Havfrue/AEC-2 subsea cable system (link to a previous blog post with details), built in cooperation with Google and Facebook, which is going to land on the Western shore of Jutland in the near future (ready for service expected in 2020-Q3). Bulk Infrastructure is going to build and operate an extension of the main cable trunk (with reduced capacity) to Norway and its datacenters present there.
It seems the DK01 Campus data center is going to act as an exchange point between other fiber networks Bulk is involved in and also landing in Esbjerg;
Havfrue
Havhingsten
Havsil
The location in Esbjerg is indicated by the orange area outline on the map below, courtesy of OpenStreetMap.
Arriving to the area from the highway driving along the Kjersing Ringvej the site is partly visible at your left hand.
Taking the 3rd exit in the roundabout onto Guldborgsundvej and turning the first left corner the site is just in front of you on the right.
Getting close the inner construction work is visible through the still open facade.
Stepping out and taking a snapshot closer to the fence.
Walking around the end of the building. Small compartments are visible.
At the other side there’s some foundation extending from the tall white wall barely visible. It is probably going to have lighter walls erected. Could be administration offices, where the high ceiling room with walls already standing is the main data center hall.
A lot of temporary arrangements on site for the construction period and site protection.
For the guests, like me, there is even a nice information board with outline map showing some details. As anticipated, offices on left side of the data center hall (right side of the building in the yellow marking, map is facing North, most pictures taken South-West). And also smaller rooms in the hall itself in the Northerne end of the building that we saw above. This is probably to be able to segment co-located equipment for restricting access.