raimue

A temporary failure means that the job failed only once and then starts running again. If you want to investigate why it failed, you will need the output of that particular failed run.

You could just wrap cronic around the command and immediately receive the full output per mail when it fails. I don't see how a heartbeat alone without logs would help to identify temporary failures.

https://habilis.net/cronic/

Your service could accomplish something similar if it had such a wrapper to report both success and failures with logs to a remote server. That would take away the need to run a local MTA, while also detecting with the heartbeat whether the job ran at all.

I already explained above why the existence of linux/landlock.h is not sufficient. Why do you still question it? If you know a bit about system programming and how configure checks work, the change in itself is totally reasonable.

Now we are running in circles. As you see in the git commit, the compile check was added because the existance of linux/landlock.h alone was not enough to check that the feature can be used.

This header defines the data types for the Linux kernel interface, but not how the syscall landlock_create_ruleset(2) will be issued. That is provided by libc either as a separate wrapper function (does not exist in glibc) or the implementation needs to use syscall(SYS_landlock_create_ruleset, ...), with the constant also being provided by libc. That is how it works for all syscalls and you won't be able to change this.

Read the code of the check again. It mostly checks that the required SYS_* constants are defined to be able to use the syscalls. You can compile this on a system that does not have landlock enabled in the running kernel, but the libc (which imports the kernel system call interface) has to provide the syscall numbers.

The question is whether you can expect this format to stay stable and reproducible across git versions. Remember the fallout from git 2.38 when the output of 'git archive' changed. Although for this backup use case it would just mean the next backup with a new format would make a full copy once.

In the 2000s, Apple ran a big campaign with the phrase "I'm a Mac - I'm a PC" to highlight the difference.

Back then, your suggestions were niche languages (and some still are) and are still not popular for embedded systems or network equipment. Large runtimes or huge static binaries are not suitable due to the memory and storage constraints.

You have to consider the surrounding ecosystem. Those interested in such languages are not necessarily those interested in contributing solutions to the problem space. Any project attempting to use such a language in OpenWrt would very likely not have survived until today.

I think the confusion comes from the documentation where ssh(1) says that the command "is executed on the remote host instead of a login shell.". Which is true from the perspective of ssh(1) in the sense of the protocol. The client has no control over what the server does with that string.

However, sshd(8) clearly documents that it will always execute the login shell, even when a command has been passed. ("All commands are run under the user's login shell as specified in the system password database.")

Subsystems open secondary channels to communicate separately from stdin/stdout of the remote command. I used the X11 forwarding before to run a remote command with sudo without getting the password prompt interfering with the protocol: https://raimue.blog/2016/09/25/how-to-run-rsync-on-remote-ho...

The author missed that sshd will always execute the user's shell and pass it the command with arguments as a `-c` argument. This means that the given command string will always be parsed by the remote shell. This is required to restrict users to certain commands with special shells like scponly or rbash.

When you keep in mind that the given command string will be parsed twice, first by your local shell and then again by the remote shell, it becomes clear why a running a remote ssh command behaves like this.

This is most probably because they are actually TIFF, but with the .png file extension they are served as image/png.

There is git-fixup, which provides the 'git fixup' command that makes suggestions to which commit the currently staged changes should be added.

https://github.com/keis/git-fixup

git-fixup will add fixup! commits, so it still needs the mentioned 'git rebase -i --autosquash' afterwards. Usually you do not even need to give it a specific commit if your branch is set to track an upstream branch.

It would be easier to intercept the open() for the /proc/cpuinfo file with a LD_PRELOAD library. Of course that would still be detectable by the benchmark. You could also use a modified libc to spoof it. Then their only way out would be static linking.

You could even just modify the kernel to report arbitrary strings in /proc/cpuinfo.

So they use the CPUID instruction instead. The CPUID instruction can be trapped to throw a SIGSEGV instead of returning real values on x86 with arch_prctl(ARCH_SET_CPUID, 0). So an injected SIGSEGV handler could then spoof it.

But even then, you could also trap the CPUID instruction in the kernel, and spoof it from there, which would be even harder to detect from user space.

In the end, the benchmark program always needs to trust the kernel. Is it really worth trying to detect spoofing?

Hamburg, as announced in an earlier blog post.

https://www.ccc.de/en/updates/2022/37-chaos-communication-co...

Previous discussion: https://news.ycombinator.com/item?id=30953634

TSO is Total Store Ordering, which refers to the memory model of x86_64. For Rosetta 2, Apple will switch the M1 processor's memory model when emulating x86_64.

The submission URL can be found on the main website by navigating in the menu to "The Site" > "About the Project".

I am sorry, but you are wrong. MacPorts will not go through configure/build/install for all ports, only those for which no binary archive can be made available. As others have already explained, this happens when license restrictions do not allow redistribution of a binary.

With your example of ffmpeg, you can check yourself that ffmpeg-4.3.2_0+gpl2.darwin_18.x86_64.tbz2 exists as a binary archive and will be used on a standard install on macOS 10.14. MacPorts will definitely not build ffmpeg from source by default.

I recommend you test again with something simpler than ffmpeg, for example bzip2 or less.

Be aware that on some distributions such as Debian or RHEL, user namespaces are restricted by default and cannot be used like this from unprivileged user accounts. Although Debian is going to change the default with the next release.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446

But selling or leaking the source code is exactly the threat used in the email as seen in the screenshot image on the linked the Twitter post.

The xorg-server port provided by MacPorts had already been a newer version than the previous official XQuartz release (from 2016) for a while.

I don't know much about WSL, but the instructions for this do not look right. Isn't WSL usually just a Linux distribution, so you should also use the package manager?

If you just run ./configure && make && sudo make install, sudo will be installed to /usr/local as prefix. Doesn't this mean the unpatched binary at /usr/bin/sudoedit will still be accessible?

Apple processes the source code before releasing it as open source, like excluding some source files and even stripping specific #ifdef sections. This can be implied from shell scripts that are part of the tarballs.

Such an approach would be way more complicated if the open source release included version control history. These code drops already always come months after the macOS releases.

To be more specific, zsh was already included before, but the default shell for new accounts is now zsh instead of bash. Apple still ships /bin/bash version 3.2 with macOS.

This seems a lot similar to hardware switches for Wi-Fi and Bluetooth devices, which are handled by rfkill. Of course, this adds support for microphone and webcam now, but wouldn't it make sense to extend rfkill? To me the purpose of these hardware switches seems close enough to be handled by a generic framework.

Yes, the man page documents the option to specify the browser on command line with -B/--browser or in the environment as RDRVIEW_BROWSER. By default it parses your mailcap preferences for text/html.

Regarding to the remapping for Y, I also only memorized y$, c$, and d$ and they seem more natural to use for me.

Therefore, I remap D to delete the whole line, but do not put it into any register. This allows me to cut a line with dd, while I can throw away a few other lines with D to clean up around the target location, before finally pasting with p.

nmap D "_dd vmap D "_dd

The save command also accepts the commit message on command line only instead of opening an editor.

I do not understand how people can live with only a single line for the commit message. For a new feature, I need to provide some details what is added and how it can be used. For a bugfix, a single line is rarely enough to describe the problem, what you changed, and why this change solves the problem.

Writing good commit messages is an essential part of using a version control system with a team. When trying to make the git interface easier, this should not be dumbed down. I would rather expect the tool to provide assistance with the usual format of a short subject and a body for a longer explanation.

I would assume the site hit its traffic limit. The password protection was then added by the web hosting service. It is accessible again right now.

Same happened to me. Luckily I could finish my read with the help of web.archive.org, which has all parts archived.