Steam Frame still alive
It seems that the Steam Frame VR headset is still alive and they actually distribute early hardware of it:
Link: VodooDE via Tiktok
This makes me happy!
Update: Seems that the video got deleted. Maybe this is a good sign.
It seems that the Steam Frame VR headset is still alive and they actually distribute early hardware of it:
Link: VodooDE via Tiktok
This makes me happy!
Update: Seems that the video got deleted. Maybe this is a good sign.
This post is part of the notes I took while preparing for and during the migration of https://perlmonks.org behind a CDN. I mostly publish these notes so that I can find them again later.
There are situations where I don't want to override the DNS resolution for my complete system, but still connect to specific machines pretending a DNS name resolves to them. Examples are SSL certificate checking, and various firewall configurations. Especially while migrating a site behind a CDN or when setting up s site beh[nd a reverse proxy or Wireguard, I want to inspect and compare the results of queries to the different machines.
For these examples, assume that 10.0.0.1 is the machine serving the website
perlmonks.org as the origin. The public DNS resolves to a pool of CDN machines
somewhere else, but we want to debug what the original source is serving.
The original machine also wants to be accessed as perlmonks.org over SSL.
curl name resolutionThis is documented in the curl manpage
curl --resolve perlmonks.org:443:10.0.0.1 https://...
Open the Firefox browser console with Ctrl+Shift+J . You should be able to enter Javascript there; If not, enable "Debugging Tools für Browser-Chrome" in the normal browser console settings (F12 , then F1 yeah, CUI standards be damned ). Then enter the name/IP pair for name resolution. This persists until you restart Firefox.
const gOverride = Cc["@mozilla.org/network/native-dns-override;1"].getService(Ci.nsINativeDNSResolverOverride);
gOverride.addIPOverride("perlmonks.org", "10.0.0.1");
For LWP::UserAgent there is no general mechanism, but monkeypatching LWP::Protocol::https works. To also make SNI work, you
should additionally pass in the SSL_hostname explicitly to the SSL options. I'm not sure why this is necessary, as the code in LWP::Protocol::https
extracts the hostname from the request URL, but this made the difference for me between 421 Misdirected Request and 200 OK with Fastly :
our $force_peeraddr;
around 'LWP::Protocol::http::_extra_sock_opts' => sub {
my $orig = shift;
die unless wantarray;
my @rv = $orig->(@_);
push @rv, PeerAddr => $force_peeraddr if defined $force_peeraddr;
return @rv;
};
around 'LWP::Protocol::https::_get_sock_info' => sub {
my $orig = shift;
my ($self, $res, $sock) = @_;
my $cert = $sock->get_peer_certificate;
my @san = $cert->peer_certificate('subjectAltNames');
use Data::Dumper; warn Dumper \@san;
while (@san) {
my ($type_id, $value) = splice @san, 0, 2;
$res->push_header("Client-SSL-Cert-SubjectAltName"
=> "$type_id: $value");
}
$orig->(@_);
};
$force_peeraddr = '10.0.0.1';
my $ua = LWP::UserAgent->new(
ssl_opts => {
verify_hostname => 0,
SSL_hostname => 'perlmonks.org', # for SNI
},
timeout => 60,
);
It seems that this is not possible.
wget name resolutionIt seems that this is not possible.
I really like live-editing documents. Interactively seeing the results of your edits makes editing more fun. For tools made by others, this would mean WYSIWYG, but for tools made by (and for) myself, I prefer the approach of editing a text file and having the conversion process kick off automatically on every file save.
For some reason, I mostly prefer editing text in a plain/small editor as ASCII. My markup needs are usually restricted to bold and italics, with a sprinkling of images and links. I don't have particular layout needs - most of that is covered by a template.
The main idea is to have two programs, one program for editing (commonly, a text editor) and one program for converting and displaying the rendered file. Instead of having a program that does the display and editing for one or more file formats, this separation allows me to use the convenient text editor that I've customized to my liking instead of a built-in text editor. It also allows me to add arbitrary intermediate steps to convert from the source to the display.
This idea is nothing new - the Emacs Flymake mode does recompilation (and other recreation) in the background whenever a source file changes as well.
With File::ChangeNotify ( and Linux::Inotify2 on Linux, respectively File::ChangeNotify::ReadDirectoryChanges for Windows, writing such tools that auto-update the viewer whenever the source file changes is really easy.
One of the programs that implement this idea is live-edit.pl.
This program runs make whenever a file in a given directory or its subdirectories changes. The Makefile
should contain the rules to regenerate the interesting content. The default rules
are only for converting LaTeX files into PDF:
# This is the default Makefile to be used by the asset reloader
# if no Makefile is found in the current directory
OPEN=xdg-open
MAYBE_OPEN=perl /home/corion/Projekte/App-LiveEdit/scripts/maybe-open.pl
.PHONY: all
all: .pdf
.pdf.tex:
pdflatex -interaction=batchmode "$<"
$(MAYBE_OPEN) "$@"
make solves the problem backwards, given a file that I want, regenerate everything
intermediate. live-edit.pl solves the problem forwards, given a file that changed, regenerate everything that depends on it.
Maybe live-edit.pl should be named ekam instead.
maybe-open.pl - this is an offshoot program that opens a file using xdg-open
if no process
is running with the file name on its command line. Highly convenient for launching
a .pdf file once in its viewer.
It's a really hard sokoban-style puzzle game about grilling sausages, with very little handholding. It does not tell any story but simply drops you into the puzzles without any explanation. On the flip side, the levels are well thought through and build on each other.
It seems to sell for €30, but I got it for 5€ in a sale, which is quite worth the money.
I struggled with the first "world", averaging maybe one or two levels a day with light play. The second world introduces three new mechanics, which make for complex puzzles again.
Unfortunately, the biggest level in the second world introduces three further mechanics and in addition also is very long and tedious, which put me off the game. I watched the solution on Youtube, and maybe I will revisit the game but that level introduces too many new mechanics without a way to play around with them, and in a setting where each of the new mechanics must be executed flawlessly in a 60+ move sequence.
It's weird but currently I draw most of my programming satisfaction from using (and enhancing) App::sqldisplay. It is a simplistic app that allows me to write and display SQL queries against a spreadsheet. I mostly use it to do the accounting for the Perl club. But doing that made doing the books much more fun actually.
Here I edit a cell in the spreadsheet, and the SQL query in the browser automatically updates and highlights the changed rows:
Also, I've now started exploring HTMX for that, and it works surprisingly well for the use case I have, removing 20+ lines of code in favour of 1 line of configuration and small Perl-side code changes.
The one thing I don't like about HTMX is that for every component of your page that you want to update individually, you need to create an HTTP accessible endpoint. But for push notifications, you can just push the new HTML instead, which is good enough.
But "even" with this hobby project, I see feature creep, as just today I thought about exporting the collection of queries as an Excel sheet. And the UI now has tabs, just like an Excel sheet and I wonder if I should keep an Excel sheet/spreadsheet for data entry or just (also) write my own editing UI. But writing an editing UI is makework for little gain. I would want it to have mostly Excel-like UI, keyboard bindings and autofill.