@EastonMan 看的新闻
+碎碎念
+膜大佬
+偶尔猫猫
+伊斯通听的歌
这个脑洞有意思
属于CYY自己的世界
Can we trust the cpu cycles from LLVM-MCA?

source
(author: 陈泱宇 (Yangyu Chen))
Daniel Lemire's blog
Thread-safe memory copy

A common operation in software is the copy of a block of memory. In C/C++, we often call the function memcpy for this purpose.

But what happens if, while you are copying the data, another thread is modifying either the source or the destination? The result is fundamentally unpredictable and almost surely a programming error.

Why would you ever code a copy function in such a way given that it is an error? Suppose you are implementing a JavaScript engine in C++, like Google v8. In JavaScript, we have SharedArrayBuffer instances that can be modified and copied from different threads. As the engineer working on the JavaScript engine, you cannot always prevent users from writing buggy code.

In any case, you get a data race:  two or more threads access the same memory location simultaneously, where at least one of the accesses is a write operation, without a synchronization mechanism to ensure that these operations occur in a specific order.

What happens? The C++ standard states that a data race results in undefined behavior. In effect, the C++ language does not tell you what happens. A crash might occur. Of course, the JavaScript engineer would rather not see a crash.

Importantly, ‘undefined behavior’ also does not tell you that there is necessarily an error. Effectively, it tells you that as programmer, you acquire the additional responsibility to ensure that it is safe code. There is no warranty coming from the programming language itself.

Why do languages like C and C++ leave undefined behavior?

A good analogy is an organization with many sub-components, where new sub-components could be added at any time. Think of an interstellar federation of planets. The interstellar federation can specify overall laws that are well defined, but there will be remaining corner cases that are specific to which planet you reside in.

That’s the spirit of C and C++: these programming languages can target a very wide range of platforms. For some of these platforms, a data race is without consequence… for others, it could be highly problematic or just slow. Also, by not specifying the behavior, it allows the compiler designer some options. So the programming language leaves it up to you to check.

Consider a conflictual memory copy where you, for example, copy from array A to array B while another thread copies from array B to array A. Under most platforms, this will not cause a crash or anything especially dangerous. You might get garbage data in your arrays, in the worst case.

But if you use automated sanitizer tools, you may still get a warning regarding the data race, even when it is inconsequential. You can silence the warning, by telling the tools that you have a check that the copy is safe.

Instead, you could roll your own ‘safe’ memory copy, where load the content byte  by byte (for example) in an atomic fashion. A possible solution in C++20 looks like so:
void safe_memcpy(char *dest, const char *src, size_t count) {
  for (size_t i = 0; i < count; ++i) {
    char input =
        std::atomic_ref<const char>(src[i])
              .load(std::memory_order_relaxed);
    std::atomic_ref<char>(dest[i])
              .store(input, std::memory_order_relaxed);
  }
}

We have now done away with any kind of undefined behavior. The code ought to be perfectly ‘safe’, there is no more data race.

So why not always use this safe approach?

Because it can be 40 times slower than a conventional memory copy.

It becomes an engineering question. Sometimes performance really does not matter.

In programming, there is practically never a free lunch. It is common that you have take your pick: aim for high performance but acquire more responsibilities, or sacrifice performance for the sake of having fewer worries.

source
杰哥的{运维,编程,调板子}小笔记

导出飞书日历为 iCalendar 格式

背景

之前用了一段时间飞书日历,想要把日历里的事件导出来备份,但是发现飞书自己的导出功能太弱,因此参考 从飞书导出日历到 Fastmail - Xuanwo's Blog 进行了导出的尝试。

导出方法

上面提到的文章,是通过 CalDAV 的方式进行的日历同步。因此我第一步也是配置飞书的 CalDAV 服务:

1. 打开飞书客户端
2. 点击设置
3. 点击日历
4. 设置 CalDAV 同步

按照界面所示,配置 CalDAV 同步,就可以得到用于 CalDAV 的域名、用户名和密码了。如果只是要订阅,那么到这一步,就可以直接用 CalDAV 客户端来同步了。但我想进一步得到 iCalendar 格式的日历文件。

于是我参考了上述文章的评论区的做法:
@jason5ng32jason5ng32Oct 28, 2024分享一下我的方法:1. 在服务器上安装 vdirsyncer ,这个工具可以同步 CalDAV 的内容,在同步设置里,不需要先找到 UUID,可以直接用飞书提供的 URL2. 写一个 Python 脚本,将 vdirsyncer 同步的内容合并成单一的 ics 文件。3. 将 ics 文件放到一个地址稍微复杂一点的 http 目录里,可以外部访问。4. 写一个 run.sh 脚本,通过 crontab 每 10 分钟执行一次 vdirsyncer 同步和日历文件合成。

也就是说,用 vdirsyncer 把日历同步到本地,再转换为 iCalendar 格式的日历文件。参考 vdirsyncer 文档,这件事情并不复杂:

1. 按照 vdirsyncer: pip3 install vdirsyncer
2. 编辑 ~/.vdirsyncer/config,填入在飞书处得到的用户密码:
[general]status_path = "~/.vdirsyncer/status/"[pair my_contacts]a = "my_contacts_local"b = "my_contacts_remote"collections = ["from a", "from b"][storage my_contacts_local]type = "filesystem"path = "~/.contacts/"fileext = ".vcf"[storage my_contacts_remote]type = "caldav"url = "https://caldav.feishu.cn"username = "REDACTED"password = "REDACTED"

3. 配置好以后,进行同步:vdirsyncer discover && vdirsyncer sync

此时在 ~/.contacts 目录下,已经能看到很多个 vcf 文件了,每个 vcf 文件对应了日历中的一个事件。实际上,这些文件就已经是 iCalendar 格式了,只不过每个文件只有一个事件。

为了让一个 .ics 文件包括日历的所有事件,写了一个脚本,实际上就是处理每个 vcf 文件,去掉每个文件开头结尾的 BEGIN:VCALENDAREND:VCALENDAR,把中间的部分拼起来,最后再加上开头结尾:
import sysall_lines = []all_lines += ["BEGIN:VCALENDAR"]for f in sys.argv[1:]: content = open(f).read().strip() lines = content.splitlines() all_lines += lines[1:-1]all_lines += ["END:VCALENDAR"]print("\n".join(all_lines))

运行上述脚本:python3 dump.py ~/.contacts/*/*.vcf > dump.ics,这样得到的 .ics 文件就可以直接导入到日历软件了。

source
Arch Linux: Recent news updates
Glibc 2.41 corrupting Discord installation

We plan to move glibc and its friends to stable later today, Feb 3. After installing the update, the Discord client will show a red warning that the installation is corrupt.

This issue has been fixed in the Discord canary build. If you rely on audio connectivity, please use the canary build, login via browser or the flatpak version until the fix hits the stable Discord release.

There have been no reports that (written) chat connectivity is affected.

source
(author: Frederik Schwan)
Daniel Lemire's blog
Programmer time and the pitfalls of wasteful work

Programmer time is precious. This realization should shape our approach to software development, focusing our efforts on tasks that genuinely contribute to the improvement of our code and the software ecosystem.

What does matter?

1. 1. Hunting for bugs. I like to add tests, and then even more tests. The time spent building tests should proportionate to the time spent building the software. Fuzzing is also fantastically useful. I love using sanitizers.
2. Fixing bugs. Bugs disrupt user experience, compromise functionality, and can even introduce security vulnerabilities. Addressing bugs is critical to build trust in the software.
3.  Documentation matters. Underdocumented code is mysterious and may trigger unnecessary surprises. Lack of documentation may also harm relationships with users.
4. Adding new features. Innovation and growth in software come from introducing new features.  Features should be user visible: ‘internal’ features are often wasteful.
5. Improving Performance. Performance enhancement is all about making the software run faster, use fewer resources, or handle larger workloads more efficiently. This can significantly impact user satisfaction, particularly in applications where speed is paramount. Improving performance is not about identify bottlenecks… it is an ongoing journey. You need a good design and multiple rounds of optimizations. You can often continue to improve the performance for years and years.

However, there are areas where I believe our time is not well spent:
Patching code to silence false positives from disabled-by-default static analyzers. The level 4 warnings under Visual Studio when compiling C++ code is a good example, but so are the obscure GCC and clang warnings. Static analyzers are tools that can scan code for potential issues without executing the program.  However, when these tools are overly strict or misconfigured, they might report numerous false positives; issues that aren’t actually problems.  Spending time patching code merely to quiet these false alarms is, in my view, wasteful. It diverts attention from more impactful work. This is not to say that static analysis is not beneficial; when used correctly, it can save considerable time and resources. But the effort required to address non-issues can quickly become counterproductive.
Aimless refactoring is also often wasteful. Renaming classes, moving code around just so that it looks ‘nice’. I am not against the occasional cleaning round… but it is should not be time consuming. Refactoring for its own sake may become an excuse for not fixing bugs or for not improving the performance. It is easy work, but often not impactful.

While we strive for perfection in our code, we must also be strategic about where we invest our most precious resource: programmer time. Let us prioritize what truly matters in the grand scheme of software development.

source
来松山湖挖华为埋在湖底的芯片了
2025 乙巳蛇年的新年红包
https://hb.lohu.info

1. 这是每年春节 Soha 的传统节目,是一个解密寻宝游戏(a.k.a. CTF),利用你的知识(现学大概也是足够的)解决所有题目,获得红包口令,口令可进入支付宝领取红包。
2. 你应该需要电脑才能愉快玩耍,但手机可能也能解一部分。不涉及任何暴力解法(爆破等)。
3. 本次活动时间从北京时间 2025 年 1 月 28 日 20 时开始,持续 24 个小时。如果红包被提前领完不会补发。
4. 这个游戏由 Soha 制作,在游戏结束后将在我的博客放出题解,往年的内容也可以在博客上找到。更多提示请在活动页面查看。
5. 最后祝大家,新年快乐!

如有疑问可以私聊 @sohajin 提出。
Back to Top