raimue

With multiple clones, you would need to remember to update each clone regulary not only from remote, but also push/pull locally in case you want to compare your state with other branches.

A 'git checkout' on a large repository such as the Linux kernel may take a while (bound by I/O performance). Regulary switching between branches with many changed files becomes annoyingly slow.

If you keep multiple clones, you actually keep multiple copies of the full history, which seems like a waste of disk space (yes, deduplicating filesystems exist, but are rarely used).

git worktrees are also very useful if you have unfinished on a release branch. You do not have to make temporary commits or stashes you forget about, you can just leave the modified files as they are and switch to a different worktree to continue your work on another branch.

In fact, due to the integration, Fossil supports offline work not only for code, but also for changes in the wiki and the issue tracker. You can do full offline development on code, update documentation in the wiki, comment on issues and change their state and merge all these changes later when you are back online.

Storing sent mails is really one of the oldest problems of the SMTP/IMAP combination.

BURL [1] is an SMTP extension that allows to submit a mail that is already stored on an IMAP server. This still requires to make a separate connection to send the mail, but at least it does not require uploading it to both SMTP and IMAP only to store it in the Sent folder.

However, this extension is rarely implemented or deployed, although the RFC itself is already twelve years old. As an example, Dovecot started to support it by acting as a SMTP proxy [2] as of version 2.3 in 2017. I am not aware of any mail clients that support BURL.

[1] https://tools.ietf.org/html/rfc4468

[2] https://wiki.dovecot.org/Submission

Yes, postfix has been around for so long and it is very solid. However, to run a mail server nowadays, it still needs a lot of configuration work and even additional daemons to add SPF checks, forwarding with SRS, and DKIM signatures. All of this is possible to be added though, which speaks for the flexibility of the postfix design.

The official sources are published by Apple on https://opensource.apple.com

This repository is just a snapshot that somebody else prepared and uploaded to GitHub, but apparently it is not maintained.

My point is that if GoDaddy modifies the HTTP body, they could as well modify the CSP you send in the HTTP header. It is yet another stop-gap, but the real solution is to get a hoster you can trust.

How would a CSP have helped here? GoDaddy injects that additional script tag right into the HTML file it serves. No policy will help if the web server does not serve what you uploaded.

Besides the supported tar features, bsdtar is definitely my favorite. With libarchive it supports all kinds of archive formats, so you can work on .zip and even .iso files with the usual command line interface.

https://github.com/libarchive/libarchive/wiki/LibarchiveForm...

To trigger the switch to a container, only the user-visible URL in the address bar is relevant. Other URLs for resources on the page do not matter at all, as they will only be loaded after you are already in the corresponding container.

The author mentions to be unsatisfied with the solution to use symlinks for finding DocBook XSL files. The correct way to reference DocBook XSL stylesheets is to use the HTTP URL to the stylesheet, which will be looked up in the XML catalog of your system. This catalog file maps URLs to files on disk and is managed by your package manager.

You should also forbid your tools to access these URLs directly (--nonet), as it would be incredicly slow and you rather want your build to fail in this case instead of downloading on-demand.

  xsltproc --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl foobar.xml

If you prefer to work with files instead of passing long URLs on command line, use a small wrapper file to import the real stylesheet and pass that on command line instead of using the URL. The advantage is that you can also put additional <xsl:param> tags to customize the output right into this file.

  <?xml version='1.0' ?>
  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>
  <!-- put additional xsl:param here -->
  </xsl:stylesheet>

Actually, just whatever 'ssh' binary is installed. That is not necessarily OpenSSH, but it is the most common choice.

At first I was not sure whether the web font was maybe not properly loading.

I did not ask any question, I stated a fact. But yes, history will be preserved. However, the point of moderation is also to delete inappropriate content, not only hide it.

Moderation is not only about voting. The titles of submissions are regularly edited, for example to add year numbers to add context when an article was published.

Of course such edits could be stored in new blocks with the information to replace the title of previous blocks. However, it would not be possible to delete any content.

On the other hand, it might also make it impossible to moderate the content.

"It looks like you're writing an email! Would you like help?"

Looks like the graph was generated from the Top 10 only. Obviously every item appears exactly once, so they all have the same 10%. The presentation as a graph is useless.

For extraction, use bsdtar from libarchive. It supports various container and compression formats. I never looked back to GNU tar, bsdtar is vastly superior.

https://github.com/libarchive/libarchive/wiki/LibarchiveForm...

What would be the reason to limit access to the beta with a waiting queue? I can see reasons to use this approach for a web app, for which you have to ensure that it scales with the number of users. There is no such problem for a standalone desktop app, though.

Most users have the mail client open all day and multi-task between reading/writing mails, reading websites, working in an office application, etc.

What would be the reason to cram the mail client into the browser instead of making it a first-class application on the same level?

Especially because they have so many projects and users they are expected to make individual calls. GitHub is the home for many open source projects and should care for the needs of their community.

The organization on GitHub was registered by an individual on behalf of the open source project. Now that the person can no longer be contacted, control needs to be transferred to someone else representing the open source project. It's that simple.

I was missing references to the time zone chaos in Egypt, so I looked it up. Apparently that started shortly after the article, but the same author also wrote about that.

https://codeofmatt.com/2016/07/01/time-zone-chaos-inevitable...

I do not see the danger of abuse. This is not about a takeover by someone entirely unrelated to the organization and repositories. This is about transferring ownership of an established open source organization to those who already have write-access to all repositories and are in fact now running the project. This seems fair when the original owner can no longer be contacted for months. Why should the organization be forced to fork because of this?

Just like .sh didn't cause confusion with the .sh extension for shell scripts.

> [...] The author is not a bot account [...]

How does GitHub identify "bot accounts"? I thought there is just one type of user accounts. You can give the API tokens generated on that account to a bot. But there is no flag in the settings to make it a "bot account".

Absolute brainfart by me. Need more coffee.

[deleted]

The Android compatibility layer is actually Alien Dalvik developed by Myriad. It is mostly used on set-top boxes for TVs. Jolla just licensed it for their phones. As far as I know, even on the latest Sailfish X, Alien Dalvik only supports the API level of Android 4.4 (2013).

Half a year ago in September, I left Sailfish OS and Jolla after I had exclusively used "alternative" mobile operating systems. I started with the Nokia N900, after that I had the Nokia N9, and then both the Jolla and Jolla C with Sailfish OS.

The UI concepts of Sailfish OS were great, the gestures were simple and intuitive. However, it lacked so many other features. The Android emulator was only compatible with apps for Android 4.4. Although being marketed as secure and privacy-aware, users have no control over apps, as there is no mandatory access control or any other permission system. Remember, this OS has been in development for over five years by now. Also, many parts of the UI stayed closed source, although Jolla promised from the beginning they want to release more open source components. If they wanted contributors, they would have more likely contributed to user-visible stuff like the mail app — not to some lower level middle-ware that is open source.

All of this and some more reasons caused me to finally pull the plug and switch to Android. I wrote about it in lengthy details here: https://raimue.blog/2018/01/09/goodbye-sailfish-os-and-jolla...

I switched as well from bzr to git. The most important thing that Git offered over alternatives was amending commits to fix mistakes, reordering commits on the local branch with 'git rebase -i', and partial checkins with the staging area. Git was the first VCS I used which could commit unrelated changes separately with ease. With other tools, you manually have to copy changes around until the working copy only contains what you want to commit.

Despite that, the Git command line interface is horribly inconsistent. Commands take separate words, `--options` or one-character flags without a scheme. Lots of synonyms such as staging area, index, or cache all meaning the same thing in the terminology does not help to make learning Git easier.

For new users I would recommend Gitless, which tries to create a better interface to git and to solve the ambiguity in commands. As Gitless is a frontend to libgit2, it works with any git repository and you can also use normal git commands. The downside is that documentation usually only shows how to do stuff with 'git'. If you only learned 'gl', you have no idea how to reproduce it.

http://gitless.com/