Our great sponsors
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gcc
-
C++ Safety, in Context
> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.
Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.
Case in point, this was fixed in both major C++ libraries:
https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...
https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...
So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?
- Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))
-
Converting the Kernel to C++
Somewhat related: In 2020 gcc bumped the requirement for bootstrapping to be a C++11 compiler [0]. Would have been fun to see the kernel finally adopt C++14 as the author suggested.
I don't think that Linus will allow this since he just commented that he will allow rust in drivers and major subsystems [1].
I do found it pretty funny that even Linus is also not writing any rust code, but is reading rust code.
I would have hoped see more answers or see something in here from actual kernel developers.
0: https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe20...
-
Understanding Objective-C by transpiling it to C++
> They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging.
Like what? So far the discussion has revolved around rewriting a linked list, which people generally shouldn't ever need to do because it's included in the standard lib for most languages. And it's a decidedly nontrivial task to do as well as the standard lib when you don't sacrifice runtime overhead to be able to handwave object lifecycle management.
- C++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...
- Rust: https://doc.rust-lang.org/beta/src/alloc/collections/linked_...
> No need to get defensive, no one is arguing that rust doesn’t do a lot of things well.
That's literally what bsaul is arguing in another comment. :)
> You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial.
Less perceived complexity. In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. For extreme use cases, the behavior and overhead of the garbage collector does became relevant.
If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust.
However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# like it is to rewrite a linked list in Rust. If we consider the languages as they're actually used, rather than an academic scenario which mostly crops up when people expect the language to behave like C or Java, the comparison is a lot more favorable than you're framing it as.
> If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust.
You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist.
So it's somewhat apples and oranges here. Yes, you may have provided your team with a linked list, but it will either
-
Committing to Rust for Kernel Code
GCC is also written in C++, and has had C++ deps since 2013:
https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-parser...
- Spitbol 360: an implementation of SNOBOL4 for IBM 360 compatible computers
-
are most computer programming languages public domain, or do their creators get a say in what you do with them?
Compliers/Interpreters are also very commonly open source (here is the source code for a popular C compiler). That means you can even modify the compiler's code and change its behavior if you wanted to.
- Learn to write production quality STL like classes
-
Which compiler is conforming here?
according to this commit, the story here seems to be much more interessting than I initially anticipated.
-
My favorite C compiler flags during development
For a more detailed explanation, see [2]. (Also the inspiration for the above example,)
[1] https://en.m.wikipedia.org/wiki/Transitive_relation
[2] https://github.com/gcc-mirror/gcc/commit/50ddbd0282e06614b29...
qemu
-
QEMU AioContext removal and how it was done
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/scsi/s...
QEMU's IOThreads allow the user to configure the threads and get something similar to thread per core architecture. But if 1 thread becomes a bottleneck, then some form of thread synchronization is needed again even with thread per core architecture. Some problems can be parallelized and they work well with thread per core.
-
Why are Apple Silicon VMs so different?
Add `ENV ERL_FLAGS="+JPperf true"` to your Dockerfile and it will build just fine cross platform. The flag just changes some things during build time and won’t affect runtime performance.
[1] https://gitlab.com/qemu-project/qemu/-/issues/1034
-
RISC-V Vector benchmark results
> I don't know how rdcycle works on qemu.
That's a good question! I had to look it up myself ...
Obviously qemu TCG isn't a cycle-accurate emulation. Using RDCYCLE / reading the corresponding CSR eventually calls https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838... which calls cpu_get_host_ticks is basically an arch-independent wrapper around RDTSC.
So it just measures the time taken to run using RDTSC. Which I guess is what you would want (maybe?). It would measure the time taken to emulate the vector instruction in host instructions.
> This benchmark is more meant for developers to figure out how to vectorize algorithms effectively, as in which instructions to choose.
Absolutely, I'm not saying the qemu results would say anything very deep, but they're kind of interesting from the point of view of either optimizing qemu or if you have to use qemu because the hardware you want isn't available / isn't cheap enough.
-
The IMPOSSIBLE RISCV HACK: Vector Extension 0.7.1-draft w/ current Linux kernel! – René Rebe
I see the commits that started switch support from RVV 071 to 100 start here, https://gitlab.com/qemu-project/qemu/-/commit/9ec6622db30df1c00d863c1ffc33341f9e0a534d
-
I booted Linux 292,612 times
>> https://gitlab.com/qemu-project/qemu/-/issues/1696 ]
> Can I please just get the detail in mail instead of having to go look at random websites?
Maybe it's me but if I did boot boot linux 292.612 times to find a bug, you might as well click a link to a repository of a major open source project on a major git hosting service.
Is it really that weird to ask people online to check a website? Maybe I don't know the etiquette of these mail lists so this is a geniune question.
-
Rise: Accelerate the Development of Open Source Software for RISC-V
Capstone is used[1] by QEMU as disassembly engine in debug logs and in monitor mode debugger, by the way, so it's in the scope of the RISE effort.
[1] https://gitlab.com/qemu-project/qemu/-/blob/master/disas/cap...
-
Intel Arc 750 Crashes Host + Display Cable Workaround not needed anymore (Windows)
A user on the qemu bugtracker found a way to get the Intel Arc working across resets without crashing the host: Just don't passthrough the audio device of the GPU and everything works!
- Qemu 7.2.2: command line syntax in libvirt domain changed
- Anyone know if there's a way to disable ReBar on only one GPU?
-
[RFT] Allow QEMU to expose static REBAR capability
[1]https://gitlab.com/qemu-project/qemu/-/commit/3412d8ec9810b819f8b79e8e0c6b87217c876e32 [2]https://gitlab.com/alex.williamson/qemu/-/commit/9a6d1822a2bd55f5dee1aec1b6529ae57949d5ba.patch
What are some alternatives?
CMake - Mirror of CMake upstream repository
riscv-binutils-gdb - RISC-V backports for binutils-gdb. Development is done upstream at the FSF.
rtl8192eu-linux-driver - Drivers for the rtl8192eu chipset for wireless adapters (D-Link DWA-131 rev E1 included!)
nbdkit
llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
CLK - A latency-hating emulator of: the Acorn Electron and Archimedes, Amstrad CPC, Apple II/II+/IIe and early Macintosh, Atari 2600 and ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga, MSX 1/2, Oric 1/Atmos, early PC compatibles, Sega Master System, Sinclair ZX80/81 and ZX Spectrum.
STL - MSVC's implementation of the C++ Standard Library.
riscv-gnu-toolchain - GNU toolchain for RISC-V, including GCC
cobol-on-wheelchair - Micro web-framework for COBOL
lzbench - lzbench is an in-memory benchmark of open-source LZ77/LZSS/LZMA compressors
busybox - The Swiss Army Knife of Embedded Linux - private tree
safeclib - safec libc extension with all C11 Annex K functions