Feeds

The second EAP build of PyCharm 2024.1 has landed and is now available for you to explore.  

You can download this new build from our website, through the free Toolbox App, or via snaps for Ubuntu.

Download PyCharm 2024.1 EAP

This new build introduces a reworked Terminal tool window and brings an ability to run or debug both client and server in a single npm configuration. Take a look!

Revamped Terminal tool window

PyCharm 2024.1 EAP 2 brings an overhauled terminal with both visual and functional enhancements to make terminal-based tasks simpler and more convenient. This update both improves the tool visually and expands its feature set.

The new Terminal tool window seamlessly integrates with the new UI, aligning it with the IDE’s refreshed look-and-feel, and it comes complete with a new color scheme that enhances readability.

One standout improvement is the presentation of each command in a distinct block. This makes it easy to identify the start and end of each one, enhancing the overall clarity of output. Easily navigate between blocks using the arrow keys or switch the focus between the prompt and output with the ⌘↑ / Ctrl + ↑ and  ⌘↓ / Ctrl + ↓ keyboard shortcuts.

We introduced a convenient command history with filtering options, making navigation through recently executed commands a breeze.

The updated terminal supports only Bash, Zsh, and PowerShell (currently only for Windows 11). We are actively working on supporting more shell integrations.

Run or debug both client and server in a single npm configuration

You can now use the same npm configuration to run and debug both the server and client sides of your application. The new Browser / Live Edit tab in the Run/Debug Configurations editor allows you to set up a run configuration to open a browser automatically after launch. If needed, you can attach the debugger to the opened browser right away.

These are the most notable updates for this week. For the full list of the implemented changes, please consult the release notes. 

Try out these new features and let us know what you think in the comments below or on X (formerly Twitter). If you encounter any bugs, please report them via our issue tracker.

Happy developing!

Ever found yourself wondering, 'Why is my Drupal site crawling at a snail's pace?' or contemplating ways to turbocharge your Drupal website performance? Essentially, what are the most efficient, budget-friendly, and quickest solutions to tackle those performance bottlenecks that are hindering your website's speed?

Fortunately, if your website is powered by Drupal 8 (and we assume it is), you're in for a treat with one of the most sophisticated caching systems available. The key lies in embracing Drupal caching best practices and leveraging its full potential.

Top 9 Essential Drupal Caching Tips

Let’s explore the top 9 Drupal caching best practices that promise to be the game-changer for your page load time. 

pytest 8.0.0 was released on 17-Jan-2024, and I’m pretty excited about it. I’m not going to cover all fo the changes, I’ll just highlight a few. For full set of changes, see the pytest changelog: Changes in 8.0.0rc1 Changes in 8.0.0rc2 Changes in 8.0.0 Version Compatibility Dropped support for Python 3.7, as it reached EOL last June. Features and Improvements Improved Diffs Improved diffs that pytest prints when an assertion fails, including:

I just bought myself a Thinkpad X1 Yoga Gen3 for $359.10. I have been quite happy with the Thinkpad X1 Carbon Gen5 I’ve had for just over a year (apart from my mistake in buying one with lost password) [1] and I normally try to get more use out of a computer than that. If I divide total cost by the time that I’ve had it working that comes out to about $1.30 per day. I would pay more than that for a laptop and I have paid much more than that for laptops in the past, but I prefer not to. I was initially tempted to buy a new Thinkpad by the prices of high end X1 devices dropping, this new Yoga has 16G of RAM and a 2560*1440 screen – that’s a good upgrade from 8G with 1920*1080. The CPU of my new Thinkpad is a quad core i5-8350U that rates 6226 [2] and is a decent upgrade from the dual core i5-6300U that rates 3239 [3] although that wasn’t a factor as I found the old CPU fast enough.

The Yoga Gen3 has a minimum weight of 1.4Kg and mine might not be the lightest model in the range while the old Carbon weighs 1.14Kg. I can really feel the difference. It’s also slightly larger but fortunately still fits in the pocket of my Scottware jacket.

The higher resolution screen and more RAM were not sufficient to make me want to spend some money. The deciding factor is that as I’m working on phones with touch screens it is a benefit to use a laptop with a touch screen so I can do more testing. The Yoga I bought was going cheap because the touch part of the touch screen is broken but the stylus still works, this is apparently a common failure mode of the Yoga.

The Yoga has a brighter screen than the Carbon and seems to have better contrast. I think Lenovo had some newer technology for that generation of laptops or maybe my Carbon is slightly defective in that regard. It’s a hazard of buying second hand that if something basically works but isn’t quite as good as it should be then you will never know.

I’m happy with this purchase and I recommend that everyone who buys laptops secondhand the way I do only get 1440p or better displays. I’ve currently got the Kitty terminal emulator [4] setup with 9 windows that each have 103 or 104 columns and 26 or 28 rows of text. That’s a lot of terminals on a laptop screen!

• [1] https://etbe.coker.com.au/2022/12/08/thinkpad-x1-carbon-gen5/
• [2] http://tinyurl.com/ysnrnelp
• [3] http://tinyurl.com/y94bdr2y
• [4] https://etbe.coker.com.au/2023/10/29/hello-kitty/

Related posts:

1. Thinkpad X1 Carbon Gen5 Gen1 Since February 2018 I have been using a Thinkpad...
2. USB-PD and GaN A recent development is cheap Gallium Nitride based power...
3. More About the Thinkpad X301 Last month I blogged about the Thinkpad X301 I got...

<p>Since Drupal 8 was released in 2015, I've launched my fair share of sites, and one common feature of those sites was a search page. Working mainly with healthcare and e-commerce businesses during that time, the sites I launched often required not just a site search but a catalog search, a find a location search, or a find a doctor search. With those additional searches came designs and requirements that I needed to convince Views, Search API, and Facets to do. Search API is great, Views is great, Facets is great, but combined, they've never worked as expected for me. Every time I build one of those experiences, it's a fight to meet the expectations of site owners. And I'm not alone. When you go to the Facets issue queue, you'll find many issues and comments reporting issues with facets.</p><p>Today, I am bundling up all my hard won search experience to introduce an easier, better way to build search experiences with Drupal. Search Web Components will take a whole class of search challenges and make it something Drupal just does instead of being a complex and time consuming part of a project.</p>

What’s new in 6.1.0? source project-dir/.virtualenvwrapper/predeactivate when deactivating source project_dir/.virtualenvwrapper/postactivate during activation

Review: Bluebird, by Ciel Pierlot

Publisher: Angry Robot Copyright: 2022 ISBN: 0-85766-967-2 Format: Kindle Pages: 458

Bluebird is a stand-alone far-future science fiction adventure.

Ten thousand years ago, a star fell into the galaxy carrying three factions of humanity. The Ascetics, the Ossuary, and the Pyrites each believe that only their god survived and the other two factions are heretics. Between them, they have conquered the rest of the galaxy and its non-human species. The only thing the factions hate worse than each other are those who attempt to stay outside the faction system.

Rig used to be a Pyrite weapon designer before she set fire to her office and escaped with her greatest invention. Now she's a Nightbird, a member of an outlaw band that tries to help refugees and protect her fellow Kashrini against Pyrite genocide. On her side, she has her girlfriend, an Ascetic librarian; her ship, Bluebird; and her guns, Panache and Pizzazz. And now, perhaps, the mysterious Ginka, a Zazra empath and remarkably capable fighter who helps Rig escape from an ambush by Pyrite soldiers.

Rig wants to stay alive, help her people, and defy the factions. Pyrite wants Rig's secrets and, as leverage, has her sister. What Ginka wants is not entirely clear even to Ginka.

This book is absurd, but I still had fun with it.

It's dangerous for me to compare things to anime given how little anime that I've watched, but Bluebird had that vibe for me: anime, or maybe Japanese RPGs or superhero comics. The storytelling is very visual, combat-oriented, and not particularly realistic. Rig is a pistol sharpshooter and Ginka is the type of undefined deadly acrobatic fighter so often seen in that type of media. In addition to her ship, Rig has a gorgeous hand-maintained racing hoverbike with a beautiful paint job. It's that sort of book.

It's also the sort of book where the characters obey cinematic logic designed to maximize dramatic physical confrontations, even if their actions make no logical sense. There is no facial recognition or screening, and it's bizarrely easy for the protagonists to end up in same physical location as high-up bad guys. One of the weapon systems that's critical to the plot makes no sense whatsoever. At critical moments, the bad guys behave more like final bosses in a video game, picking up weapons to deal with the protagonists directly instead of using their supposedly vast armies of agents. There is supposedly a whole galaxy full of civilizations with capital worlds covered in planet-spanning cities, but politics barely exist and the faction leaders get directly involved in the plot.

If you are looking for a realistic projection of technology or society, I cannot stress enough that this is not the book that you're looking for. You probably figured that out when I mentioned ten thousand years of war, but that will only be the beginning of the suspension of disbelief problems. You need to turn off your brain and enjoy the action sequences and melodrama.

I'm normally good at that, and I admit I still struggled because the plot logic is such a mismatch with the typical novels I read. There are several points where the characters do something that seems so monumentally dumb that I was sure Pierlot was setting them up for a fall, and then I got wrong-footed because their plan worked fine, or exploded for unrelated reasons. I think this type of story, heavy on dramatic eye-candy and emotional moments with swelling soundtracks, is a lot easier to pull off in visual media where all the pretty pictures distract your brain. In a novel, there's a lot of time to think about the strategy, technology, and government structure, which for this book is not a good idea.

If you can get past that, though, Rig is entertainingly snarky and Ginka, who turns out to be the emotional heart of the book, is an enjoyable character with a real growth arc. Her background is a bit simplistic and the villains are the sort of pure evil that you might expect from this type of cinematic plot, but I cared about the outcome of her story. Some parts of the plot dragged and I think the editing could have been tighter, but there was enough competence porn and banter to pull me through.

I would recommend Bluebird only cautiously, since you're going to need to turn off large portions of your brain and be in the right mood for nonsensically dramatic confrontations, but I don't regret reading it. It's mostly in primary colors and the emotional conflicts are not what anyone would call subtle, but it delivers a character arc and a somewhat satisfying ending.

Content warning: There is a lot of serious physical injury in this book, including surgical maiming. If that's going to bother you, you may want to give this one a pass.

Rating: 6 out of 10

This a lazy and anti-rant post… I want to shine a light on the fantastic KDE software that I use daily. You can do similar things with GNOME and whatever else, but that’s for someone else to write. I have some bias because I have contributed to several of these applications, but that doesn’t detract from the point that I depend on them daily.

Screenshot of KMail from kde.org

I check my work and personal mail using KMail. I’m one of those lucky few that checks my mail from two IMAP-compliant servers, so I steer clear from Outlook/GMail. I keep track of tasks, events and meetings using Merkuro. I can keep tabs on my calendar since the time applet is synced thanks to Akonadi. I really enjoy and use the integration between these Akonadi applications, such as accepting invitations to meetings which are automatically recorded into my calendar.

My work uses Rocket.Chat, and I use Ruqola for interacting with that:

Screenshot of Ruqola from kde.org

Even when not working, I still use KDE software! One of them is drawing, and I use Krita for that (which is a great application in general, you should use it!) It’s completely replaced Procreate and Clip Studio Paint which I used before. I really like it’s integrated brush engines and default brush set, along with all of it’s built-in functionality like animation support. I even use Krita when sketching on-the-go or in bed now instead of Procreate, since my Lenovo Yoga runs Linux and KDE Plasma. When I edit videos, my program of choice is Kdenlive (which is a great application in general, you should use it!) It does everything I want it to do, honestly I have very little trouble with it but my needs are minimal.

Screenshot of Kdenlive from kde.org

My primary chat platform is Matrix, so of course I use NeoChat as my preferred client everywhere I can. I chose Mastodon as my Twitter-replacement, and I use Tokodon so much that I don’t even open up their web interface anymore! The less I have to run in the browser the better, in my opinion.

Screenshot of Tokodon from kde.org

There’s also lots of small utilities that I use, such as Spectacle for screenshots and quick screen recordings. I use Kate for all of my text editing, such as this post right now! Gwenview is my image viewer of choice too. Of course I use Okular for reading the occasional PDF. Can’t forget about Okteta when I’m trying to dissect some binary file.

Screenshot of Kasts from kde.org

I even use KDE applications for consuming media, too. I use PlasmaTube to feed my YouTube addiction. I like to put videos in picture-in-picture and even added that to the next release, meaning I can stop using the web interface for Invidious. I have started listening to some podcasts, and have been using Kasts for those. I elarned recently that it even can sync via NextCloud!

Upcoming #

Here’s some software I recently learned about, and want to start using soon:

• Accessibility Inspector, which is a KDE-based alternative to GNOME’s Accerciser.
• Codevis, a code visualization program, I used it once before but I need to try it again.
• Fielding, a REST API client. I plan to expand it’s features further so I don’t have to depend on Insomina.
• Powerplant, something to help keep your plants. I only have one plant to keep right now, so this is the perfect time to learn how to use it!

Hope this sheds some light on my favorite applications, and gives you ideas for using them! I enjoy how fast these applications are, and how integrated and nice they all look together. I couldn’t go over every single one, but maybe I can expand in the future.

Over the last weekend i had some spare time to improve qmpbackup a little more, the new version:

• Uses blockdev-backup QMP commands instead of the soon to be deprecated drive-backup.
• Adds --compress option: target QCOW files data can be compressed.
• Adds --speed-limit option to limit backup speed throughput.
• Adds --include-raw option so attached raw devices can be backed up too.
• Allows backing up virtual machines in paused or pre-running state.
• Adds backup option copy to allow backing up virtual machines with older qcow image formats, that are not supporting persistent bitmaps.
• Improved logging output.

and some minor code reworks. Hope its useful for someone.

This article looks at how to work with static and media files in a Django project, locally and in production.

An “IndexError: list index out of range” in Python typically occurs when you’re trying to access an index in a list that does not exist. This typically happens when attempting to access an index that is beyond the bounds of the list. In this guide, we’ll explore the causes of this error and discuss various […]

The post IndexError: List Index Out of Range in Python appeared first on TechBeamers.

In my previous blog post Providing online reference documentation for debputy, I made a point about how debhelper documentation was suboptimal on account of being static rather than online. The thing is that debhelper is not alone in this problem space, even if it is a major contributor to the number of packaging files you have to to know about.

If we look at the "competition" here such as Fedora and Arch Linux, they tend to only have one packaging file. While most Debian people will tell you a long list of cons about having one packaging file (such a Fedora's spec file being 3+ domain specific languages "mashed" into one file), one major advantage is that there is only "the one packaging file". You only need to remember where to find the documentation for one file, which is great when you are running on wetware with limited storage capacity.

Which means as a newbie, you can dedicate less mental resources to tracking multiple files and how they interact and more effort understanding the "one file" at hand. I started by asking myself how can we in Debian make the packaging stack more accessible to newcomers? Spoiler alert, I dug myself into rabbit hole and ended up somewhere else than where I thought I was going.

I started by wanting to scan the debian directory and annotate all files that I could with documentation links. The logic was that if debputy could do that for you, then you could spend more mental effort elsewhere. So I combined debputy's packager provided files detection with a static list of files and I quickly had a good starting point for debputy-based packages.

Adding (non-static) dpkg and debhelper files to the mix

Now, I could have closed the topic here and said "Look, I did debputy files plus couple of super common files". But I decided to take it a bit further. I added support for handling some dpkg files like packager provided files (such as debian/substvars and debian/symbols). But even then, we all know that debhelper is the big hurdle and a major part of the omission...

In another previous blog post (A new Debian package helper: debputy), I made a point about how debputy could list all auxiliary files while debhelper could not. This was exactly the kind of feature that I would need for this feature, if this feature was to cover debhelper. Now, I also remarked in that blog post that I was not willing to maintain such a list. Also, I may have ranted about static documentation being unhelpful for debhelper as it excludes third-party provided tooling.

Fortunately, a recent update to dh_assistant had provided some basic plumbing for loading dh sequences. This meant that getting a list of all relevant commands for a source package was a lot easier than it used to be. Once you have a list of commands, it would be possible to check all of them for dh's NOOP PROMISE hints. In these hints, a command can assert it does nothing if a given pkgfile is not present. This lead to the new dh_assistant list-guessed-dh-config-files command that will list all declared pkgfiles and which helpers listed them.

With this combined feature set in place, debputy could call dh_assistant to get a list of pkgfiles, pretend they were packager provided files and annotate those along with manpage for the relevant debhelper command. The exciting thing about letting debpputy resolve the pkgfiles is that debputy will resolve "named" files automatically (debhelper tools will only do so when --name is passed), so it is much more likely to detect named pkgfiles correctly too. Side note: I am going to ignore the elephant in the room for now, which is dh_installsystemd and its package@.service files and the wide-spread use of debian/foo.service where there is no package called foo. For the latter case, the "proper" name would be debian/pkg.foo.service.

With the new dh_assistant feature done and added to debputy, debputy could now detect the ubiquitous debian/install file. Excellent. But less great was that the very common debian/docs file was not. Turns out that dh_installdocs cannot be skipped by dh, so it cannot have NOOP PROMISE hints. Meh...

Well, dh_assistant could learn about a new INTROSPECTABLE marker in addition to the NOOP PROMISE and then I could sprinkle that into a few commands. Indeed that worked and meant that debian/postinst (etc.) are now also detectable.

At this point, debputy would be able to identify a wide range of debhelper related configuration files in debian/ and at least associate each of them with one or more commands.

Nice, surely, this would be a good place to stop, right...?

Adding more metadata to the files

The debhelper detected files only had a command name and manpage URI to that command. It would be nice if we could contextualize this a bit more.

Like is this file installed into the package as is like debian/pam or is it a file list to be processed like debian/install. To make this distinction, I could add the most common debhelper file types to my static list and then merge the result together.

Except, I do not want to maintain a full list in debputy. Fortunately, debputy has a quite extensible plugin infrastructure, so added a new plugin feature to provide this kind of detail and now I can outsource the problem! I split my definitions into two and placed the generic ones in the debputy-documentation plugin and moved the debhelper related ones to debhelper-documentation. Additionally, third-party dh addons could provide their own debputy plugin to add context to their configuration files.

So, this gave birth file categories and configuration features, which described each file on different fronts. As an example, debian/gbp.conf could be tagged as a maint-config to signal that it is not directly related to the package build but more of a tool or style preference file. On the other hand, debian/install and debian/debputy.manifest would both be tagged as a pkg-helper-config. Files like debian/pam were tagged as ppf-file for packager provided file and so on.

I mentioned configuration features above and those were added because, I have had a beef with debhelper's "standard" configuration file format as read by filearray and filedoublearray. They are often considered simple to understand, but it is hard to know how a tool will actually read the file. As an example, consider the following:

• Will the debhelper use filearray, filedoublearray or none of them to read the file? This topic has about 2 bits of entropy.
• Will the config file be executed if it is marked executable assuming you are using the right compat level? If it is executable, does dh-exec allow renaming for this file? This topic adds 1 or 2 bit of entropy depending on the context.
• Will the config file be subject to glob expansions? This topic sounds like a boolean but is a complicated mess. The globs can be handled either by debhelper as it parses the file for you. In this case, the globs are applied to every token. However, this is not what dh_install does. Here the last token on each line is supposed to be a directory and therefore not subject to globs. Therefore, dh_install does the globbing itself afterwards but only on part of the tokens. So that is about 2 bits of entropy more. Actually, it gets worse...
  • If the file is executed, debhelper will refuse to expand globs in the output of the command, which was a deliberate design choice by the original debhelper maintainer took when he introduced the feature in debhelper/8.9.12. Except, dh_install feature interacts with the design choice and does enable glob expansion in the tool output, because it does so manually after its filedoublearray call.

So these "simple" files have way too many combinations of how they can be interpreted. I figured it would be helpful if debputy could highlight these difference, so I added support for those as well.

Accordingly, debian/install is tagged with multiple tags including dh-executable-config and dh-glob-after-execute. Then, I added a datatable of these tags, so it would be easy for people to look up what they meant.

Ok, this seems like a closed deal, right...?

Context, context, context

However, the dh-executable-config tag among other are only applicable in compat 9 or later. It does not seem newbie friendly if you are told that this feature exist, but then have to read in the extended description that that it actually does not apply to your package.

This problem seems fixable. Thanks to dh_assistant, it is easy to figure out which compat level the package is using. Then tweak some metadata to enable per compat level rules. With that tags like dh-executable-config only appears for packages using compat 9 or later.

Also, debputy should be able to tell you where packager provided files like debian/pam are installed. We already have the logic for packager provided files that debputy supports and I am already using debputy engine for detecting the files. If only the plugin provided metadata gave me the install pattern, debputy would be able tell you where this file goes in the package. Indeed, a bit of tweaking later and setting install-pattern to usr/lib/pam.d/{name}, debputy presented me with the correct install-path with the package name placing the {name} placeholder.

Now, I have been using debian/pam as an example, because debian/pam is installed into usr/lib/pam.d in compat 14. But in earlier compat levels, it was installed into etc/pam.d. Well, I already had an infrastructure for doing compat file tags. Off we go to add install-pattern to the complat level infrastructure and now changing the compat level would change the path. Great. (Bug warning: The value is off-by-one in the current version of debhelper. This is fixed in git)

Also, while we are in this install-pattern business, a number of debhelper config files causes files to be installed into a fixed directory. Like debian/docs which causes file to be installed into /usr/share/docs/{package}. Surely, we can expand that as well and provide that bit of context too... and done. (Bug warning: The code currently does not account for the main documentation package context)

It is rather common pattern for people to do debian/foo.in files, because they want to custom generation of debian/foo. Which means if you have debian/foo you get "Oh, let me tell you about debian/foo ". Then you rename it to debian/foo.in and the result is "debian/foo.in is a total mystery to me!". That is suboptimal, so lets detect those as well as if they were the original file but add a tag saying that they are a generate template and which file we suspect it generates.

Finally, if you use debputy, almost all of the standard debhelper commands are removed from the sequence, since debputy replaces them. It would be weird if these commands still contributed configuration files when they are not actually going to be invoked. This mostly happened naturally due to the way the underlying dh_assistant command works. However, any file mentioned by the debhelper-documentation plugin would still appear unfortunately. So off I went to filter the list of known configuration files against which dh_ commands that dh_assistant thought would be used for this package.

Wrapping it up

I was several layers into this and had to dig myself out. I have ended up with a lot of data and metadata. But it was quite difficult for me to arrange the output in a user friendly manner.

However, all this data did seem like it would be useful any tool that wants to understand more about the package. So to get out of the rabbit hole, I for now wrapped all of this into JSON and now we have a debputy tool-support annotate-debian-directory command that might be useful for other tools.

To try it out, you can try the following demo:

In another day, I will figure out how to structure this output so it is useful for non-machine consumers. Suggestions are welcome. :)

Limitations of the approach

As a closing remark, I should probably remind people that this feature relies heavily on declarative features. These include:

• When determining which commands are relevant, using Build-Depends: dh-sequence-foo is much more reliable than configuring it via the Turing complete configuration we call debian/rules.
• When debhelper commands use NOOP promise hints, dh_assistant can "see" the config files listed those hints, meaning the file will at least be detected. For new introspectable hint and the debputy plugin, it is probably better to wait until the dust settles a bit before adding any of those.

You can help yourself and others to better results by using the declarative way rather than using debian/rules, which is the bane of all introspection!

Long Now has an insightful article about domestication that considers whether humans have evolved to want to control nature [1].

The OMG Elite hacker cable is an interesting device [2]. A Wifi device in a USB cable to allow remote control and monitoring of data transfer, including remote keyboard control and sniffing. Pity that USB-C cables have chips in them so you can’t use a spark to remove unwanted chips from modern cables.

David Brin’s blog post The core goal of tyrants: The “Red-Caesar” Cult and a restored era of The Great Man has some insightful points about authoritarianism [3].

Ron Garret wrote an interesting argument against Christianity [4], and a follow-up titled Why I Don’t Believe in Jesus [5]. He has a link to a well written article about the different theologies of Jesus and Paul [6].

Dimitri John Ledkov wrote an interesting blog post about how they reduced disk space for Ubuntu kernel packages and RAM for the initramfs phase of boot [7]. I hope this gets copied to Debian soon.

Joey Hess wrote an interesting blog post about trying to make LLM systems produce bad code if trained on his code without permission [8].

Arstechnica has an interesting summary of research into the security of fingerprint sensors [9]. Not surprising that the products of the 3 vendors that supply almost all PC fingerprint readers are easy to compromise.

Bruce Schneier wrote an insightful blog post about how AI will allow mass spying (as opposed to mass surveillance) [10].

ZDnet has an informative article How to Write Better ChatGPT Prompts in 5 Steps [11]. I sent this to a bunch of my relatives.

AbortRetryFail has an interesting article about the Itanic Saga [12]. Erberus sounds interesting, maybe VLIW designs could give a good ration of instructions to power – unlike the Itanium which was notorious for being power hungry.

Bruce Schneier wrote an insightful article about AI and Trust [13]. We really need laws controlling these things!

David Brin wrote an interesting blog post on the obsession with historical cycles [14].

• [1] http://tinyurl.com/2xf9wb9k
• [2] http://tinyurl.com/2m82ajju
• [3] http://tinyurl.com/yrjp5la6
• [4] http://tinyurl.com/ytdb24xm
• [5] http://tinyurl.com/2x6b7wbd
• [6] https://doctrine.org/jesus-vs-paul
• [7] http://tinyurl.com/yp3xqtr3
• [8] https://joeyh.name/blog/entry/attribution_armored_code/
• [9] http://tinyurl.com/ywus4o47
• [10] http://tinyurl.com/ypzkjyfv
• [11] http://tinyurl.com/yp6ldxlr
• [12] https://www.abortretry.fail/p/the-itanic-saga
• [13] http://tinyurl.com/yqh9wbfj
• [14] http://tinyurl.com/ylue4svh

Related posts:

1. Links January 2020 C is Not a Low Level Language [1] is an...
2. Links January 2023 The Intercept has an amusing and interesting article about senior...
3. Links January 2021 Krebs on Security has an informative article about web notifications...

Aim: Aim is a self-hostable machine learning experiment tracker designed to handle 10,000s of training runs.

Links:

• Repo
• Home
• Blog

explainshell.com: A web-based tool to match command-line arguments to their man pages and help text.

Links:

• Repo
• Home

liberapay.com: A recurrent donations platform, formerly known as gittip and gratipay.

Links:

• Repo
• Home
• WP

Mathesar: Self-hostable web application which provides a spreadsheet-like interface to a PostgreSQL database, enabling users of all technical skill levels to design data models, enter data, and build reports.

Links:

• Repo
• Home
• Demo
• Fund
• Docs

Dispatch: Incident management service featuring integrations for notifications and task management. Used at Netflix.

Links:

• Repo
• Blog
• Docs

Mealie: Self-hostable recipe management server with rich user interface and automatic backups.

Links:

• Repo
• Home
• Demo
• Fund
• Docs

Open Event Server: Enable event organizers to manage events from meetups to concerts to conferences, with support for multiple tracks and venues. Used by [FOSSASIA](https://fossasia.org/) and [eventyay](https://eventyay.com/).

Links:

• Repo
• Demo