I can of agree the focus to make Linux easy to use is not exactly on the right things. There is a bit too much of a "make a GUI of everything". Which is not wrong per say, but should not be the goal. More a mean to an end.

I disagree that users won't do stuff on their own. They will, but they will allocate very little time to it, on average, especially when compared to a tech savy person. And that's just because their computer is a tool.And if they cannot make their tool work for what they want to do, they'll find another way. Or deem it impossible.

I think distro must make mundane tasks such as system maintenance hands off. As an opt-in option not to upset power user. But things such as updates, full system update, disk space reclaiming, ... should have a single "do the right thing without being asked to" toggle. Things a bit more complicated such as printing/scanning document should be more context aware. A bit like on smartphone where, if you have a document open, you can select print and, if no printer is configured, you have the option to add one there and then.

Immutable distro have made good progress on that front IMO. But we still need better integration between applications and the Desktop Environment for things like printing, sharing and so on. I'm hopeful though. Generally speaking, things are moving in that direction. Even if we can argue flapak and snap are a step backward with regards to the integration of the DE, this is also an opportunity to formalize some form of protocol with the DE.

the common practice is to relax the dependencies

I found this a bit disturbing

I find that funny that, since this is rust, this is now an issue.

I have not dwelved in packaging in a long while, but I remember that this was already the case for C programs. You need to link against libfoo? It better work with the one the distribution ship with. What do you mean you have not tested all distributions? You better have some tests to catch those elusive ABI/API breakage. And then, you have to rely on user reported errors to figure out that there is an issue.

On one hand, the package maintainer tend to take full ownership and will investigate issues that look like integration issue themselves. On the other hand, your program is in a buggy or non-working state until that's sorted.

And the usual solutions are frown upon. Vendoring the dependencies or static linking? Are you crazy? You're not the one paying for bandwidth and storage. Which is a valid concern, but that just mean we reached a stalemate.

Which is now being broken by

• slower moving C/C++ projects (though the newer C++ standards did some waves a few years back) which means that even Debian is likely to have a "recent" enough version of your dependencies.
• flatpack and the likes, which are vendoring everything and the kitchen sink
• newer languages that static link by default (and some distributions being OK with it)

In other words, we never figured out a proper solution for C projects that will link with a different minor than the one the developer tested.

Well, /rant I guess. The point I'm raising does not seem to be the only one, and maybe far from the main one, for which bcachefs-tools is now orphaned. But I've seen very dubious arguments to try and push back against rust adoption. I feel like people have forgotten where we came from. And while there is no reason to go back per say, any new language that integrate this deep into the system will face similar challenges.

I think both models (i.e. allowlist/blocklist) have their own perks and drawbacks and are all necessary for a healthy and enjoyable internet.

I would tend to agree. I think both methods have their merits. Though ideally I'd rather have most instances use a blocklist model. This is less cumbersome to the average user and this achieves (in my opinion) one of fediverse goal of having an online identity not tied to an instance, an online identity you can easily migrate (including comments, follow, DMs, ...) if needed.

But the blocklist model is too hard to maintain at this time. There are various initiative to try and make it work, such as fediseer, and it might be good enough for most. But I think it's a trap we should not fall into. On the fediverse, "good enough for most" is not good enough.

Now that people are fleeing to the Fediverse, we’re just gathering our tribe - and this is a natural phenomenon.

I think there is indeed something of that effect going on as well, this is true. But I do not think this warrants a move to allowlist by itself.

I think the move to allowlist is mandated by the fact that building a safe space for "minorities" is hard. The tools to alleviate issues such as harassment and bigotry are not sufficient at this time to keep those communities fully open.

Which is a shame as I think the best way to fight those issues, as a society, is to have people express themselves and have healthy conversation on issues that are rarely brought up.

But we are not entirely giving that up by moving to an archipelago model. It just means that individuals would have multiple accounts, on different archipelago. The downside is that it makes the fediverse less approachable to the average person.

What a shit show. And if it is confirmed that laptop CPU are also affected, even if to a lower extent, AMD will be the only option on consumer hardware in the coming couple of years. Thankfully, Qualcomm entered the scene recently which should stir up the competition and prevent AMD from resting on its laurels.

Enable permissions for KMS capture.

Warning

Capture of most Wayland-based desktop environments will fail unless this step is performed.

Note

cap_sys_admin may as well be root, except you don’t need to be root to run it. It is necessary to allow Sunshine to use KMS capture.

Enable

   sudo setcap cap_sys_admin+p $(readlink -f $(which sunshine))

Disable (for Xorg/X11 only)

   sudo setcap -r $(readlink -f $(which sunshine))

Their install instruction are pretty clear to me. The actual instruction is to run

sudo setcap cap_sys_admin+p $(readlink -f $(which sunshine))

This is vaguely equivalent to setting the setuid bit on programs such as sudo which allows you to run as root. Except that the program does not need to be owned by root. There are also some other subtleties, but as they say, it might as well be the same as running the program directly as root. For the exact details, see here: https://www.man7.org/linux/man-pages/man7/capabilities.7.html and look for CAP_SYS_ADMIN.

In other words, the commands gives all powers to the binary. Which is why it can capture everything.

Using KMS capture seems way overkill for the task I would say. But maybe the wayland protocol was not there yet when this came around or they need every bit of performance they can gain. Seeing the project description, I would guess on the later as a cloud provider would dedicate a machine per user and would then wipe and re-install between two sessions.

I would not have expected anyone to go to ASUS' office to press the issue. So, good on GN and hopefully will see some long-term results. But seeing how the company has a hard time acknowledging some issues such as the ROG Ally SD card one, I would not hold my breadth.

The main problem is that dynamic linking is hard. It is not just easier for the maintainers of the languages to ignore it, it removes an entire class of problems.

Dynamic linking does not even reliably work with C++, an "old" language with decades of tooling and experience on the matter. You get into all kind of UB when interacting with a separate DSO, especially since there are minimal verification of the ABI compatibility when loading a dynamic library. So you have to wait for a crash to be certain you got it wrong. Unless you control the compilation of your dependencies, it's fairly hard to be certain you won't encounter dynamic linking related issues. At which point you realize that, if the license allows it, you're better off static linking everything, including the C++ library itself: it makes it much more predictable, you're not forcing an additional dependency on your users and most UB are now gone (especially the one about raising exception across DSO boundaries, which can happen behind your back, unless you control the compilation of all your dependencies...).

That's especially true if you are releasing a library where you do not know it's runtime: it might be dynamically loaded via dlopen by a C++ binary that will load its own C++ library first, but some of your users use the version that is stuck on C++14 and your codebase is in C++23. This can be solved, by playing with LD_LIBRARY_PATH, but the application is already making use of it to load the C++ library it comes with instead of the one provided by the system (which only provides C++11 runtime), and it completely ignores the initial state of the environment variable (how could it do otherwise? It would have to guess the path to the libstdc++ is for a newer version and not the older one provided by the system). Now imagine the same issue with your own transitive dependency on top of that: it's a nightmare.

So dynamic linking never really worked, except maybe for C when you expect a single level of dependency, all provided by the system. And even then that's mostly thanks to C simpler ABI and runtime.

So I expect that is the main reason newer languages do not bother with dynamic linking: it introduces way too many issues. Look at your average rust program and how many version of a same dependency it loads, transitively. How would you solve that problem as to be able to load different versions when it matters but try first and foremost to load only one if possible? How would you be able to make the right call? By using semver? If nobody made any mistake why not, but you will rather be required to provide escape hatches that, much like LD_LIBRARY_PATH and LD_PRELOAD, will be misused. And by then, you only "solved" the simplest problem.

Nowadays, based on how applications are delivered on Windows and OSX, and with the advent of docker, flatpack/snap and appimage, I do not see a way back to dynamic linking anytime soon. It's just too complicated of a problem, especially as the number of dependency grows.

The reason behind kernel mode/user mode separation is to require all user-land programs to have to go through the kernel to do any modification to the system. In other words, would it not be for syscalls, the only thing a user land program could do would be to burn CPU cycles. And even then, the kernel can still preempt it any time to let other, potentially more important programs, run instead.

So if a program can harm your system from userland, it's because the kernel allowed it, every time. Which is why we currently see a slow move toward sandboxing everything. Basically, the idea of sandboxing is to give the kernel enough information about the running program so that we can tailor which syscalls it can do and with which arguments. For example: you want to prevent an application from accessing the network? Prevent it from allocating sockets through the associated syscall.

The reason for this slow move is historical really: introducing all those protections from the get go would require a lot of development time to start with, but it had to be built unpon non-existant security layers and not break all programs in the process. CPUs were not even powerful enough to waste cycles on such concerns.

Now, to better understand user mode/kernel mode, you have to realize that there are actually more modes than this. I can only speak for the ARM architecture because it's the one I know, but x86 has similar mechanisms. Basically, from the CPU perspective, you have several privilege levels. On x86 those are called rings, on ARM, they're called Exception Level. On ARM, a CPU has up to four of those, EL3 to EL0. They also have names based on their purpose (inherited from ARMv7). So EL3 is firmware level, EL2 is hypervisor, EL1 is system and EL0 is user. A kernel typically run on EL2 and EL1. EL3 is reserved for the firmware/boot process to do the most basic setup, partly required by the other ELs. EL2 is called hypervisor because it allows to have several virtual EL1 (and even EL2). In other words, a kernel running at EL2 can run several other kernels at EL1: this is virtualization and how VMs are implemented. Then you have your kernel/user land separation with most of the kernel (and driver) logic running at EL1 and the user programs running at EL0.

Each level allocates resources for the sub-level (under the form of memory map, as memory maps, which do not necessarily map to RAM, are also used to talk to devices). Would a level try to access a resource (memory address) it has no rights to, an exception would be raised to the upper level, which would then decide what to do: let it through or terminate the program (the later translates to a kernel panic/BSOD when the program in question is the kernel itself or a segmentation fault/bus error for user land programs).

This mechanism is fairly easy to understand with the swap mechanism: the kernel allows your program to access some page in memory when asked through brk or mmap, used by malloc. But then, when the system is under memory pressure, and it turns out your program has not used that memory region for a little while, the kernel swaps it out. Which means your program is now forbidden from accessing this memory. When the program tries to access that memory again, the kernel is informed of the action through a exception raised (unintentionally) by your program. The kernel then swaps back the memory region from disk, allows your program to access the memory region again, and then let the program resume to a state prior to the memory access (that it will then re-attempt without even realizing).

So basically, a level is fully responsible for what a sub-level does. In theory, you could have no protection at all: EL1 (the kernel) could allow EL0 to modify all the memory EL1 has access to (again, those are memory maps, that can also map to devices, not necessarily RAM). In practice, the goal of EL1 is to let nothing through without being involved itself: the program wants to write something on the disk: syscall, wants more memory: syscall, wants to draw something on the screen: syscall, use the network: syscall, talk to another program: syscall.

But the reason is not only security. It is also, and most importantly, abstraction. For example, when talking to a USB device, a user program does not have to know the USB protocol. This is implemented once in the kernel and then userland programs can use that to deal with all the annoying stuff such as timings, buffers, interruptions and so on. So the syscalls were initially designed for that: build a library of functions all user programs can re-use without having to re-implement them, or worse, without having to deal with the specifics of every device/vendor: this is the sole responsibility of the kernel.

So there you have it: a user program cannot harm the computer without going through the kernel first. But the kernel allows it nonetheless because it was not initially designed as a security feature. The security concerns came afterward and were initially implemented with users, which are mostly enough for servers, and where root has nearly as many privileges as the kernel itself (because the kernel allows it). Those are currently being improved under the form of sandboxes, for which the work started a while ago, with every OS (and CPU architecture) having its own implementation. But we are only seeing widespread adoption by userland since fairly recently on desktop. Partly thanks to the push from smartphones where application-level privileges (to access the camera for example) were born AFAIK.

Nowadays, CPUs are powerful enough to even have security features to try to protect a userland program from itself: from buffer overflow, return address manipulation and the like. If you're interested, I recommend you look at the concept of pointer authentication.

I feel like since Glassdoor has a job board, there is an obvious conflict of interest that cannot be solved and ultimately yields to the company review part to be mostly useless. If you browse through a few company profiles, some that offer jobs on Glassdoor (and reply to reviews) and some that do not, you will quickly see what I'm talking about.

I mean, who is going to post job offers on a board that also list your company at <4 stars with plenty of mention of "bad company culture" and "horrendous working condition"?

I also do not like how most of the would-be-intersting-info is gatekeep behind you sharing various info on your own employer. I mean, it seems to make sense on the surface, but with the above, the whole thing feels like a scam. Where both employers and employees get scammed.

How does it compare to alternatives ? Well, LinkedIn is terrible, with abysmal search function, results completely irrelevant to your profile, and the same seems to be true for recruiters seeing how often I'm proposed jobs completely outside of my skillset.

So I guess Glassdoor is a viable source of job offer, especially if you have already selected companies you'd like to work at and those companies do not have their own board. But take all reviews and comments with a huge grain of salt.

First of, especially in C, you should very carefully read the documentation of the functions you use. It then should be obvious to you you are currently misusing it on two accounts:

• You are not checking for errors
• You are assuming the presence of a \n that might never be there (this one leads to your unexpected behavior)

The manual tells you it will insert a \0 at the end of what it reads within the limits of the buffer. So this \0 is what you will need to look for when determining the size of the input.

If there is a \n, it will precede the \0. Just make sure the \0 is not at index 0 before trying to erase the \n. If there is no \n before the \0, you are in either of two cases (again, this is detailed in the documentation): the input is truncated (you did not read the full line, as in your unexpected behavior above) or you are reaching the end of the stream. Note that even if the stream ends with \n, you might need to issue an additional fgets to know you are at the end of the stream in which case a \0 will be placed as the first byte of your buffer.

If you really want to handle input that exceeds your initial buffer, then you need to dynamically allocate one and grow it as needed. A well behaved program will have an upper limit to the size of the input anyway (and this is why you don't use gets). So you will need a combination of malloc/realloc and string concatenation. That means you need to learn all the pitfalls of dynamic memory allocation in C and how to use valgrind. For the string concatenation, even though strcat should be OK in your case, I'd recommend against it.

In order to use strcat properly you need to keep track of the usage of the dynamically allocated buffer by hand anyway because you want to know when you will attempt to store more bytes in the buffer than is currently allocated. And once you know the number of bytes stored in the buffer, copying over the bytes that fgets returns by hand is fairly trivial and has less pitfalls. This also circumvent one of the performance pitfall of strcat: it needs to find the \0 in the destination buffer for every call. So effectively, it can transform all by itself a trivial usecase such as yours, that one would expect to be linear in algorithmic complexity, to be of O(N^2) complexity.

On a final note: fgets does not allow you to handle binary data properly because you wont be able to tell apart a legitimate \0 coming from your input from a \0 inserted by fgets. So you will need to use fread in this case. I actually recommend using fread instead of fgets because it directly returns the number of bytes read, no need to use strlen to guess it and it makes error handling easier. Though you'll need to add the trailing \0 yourself.

I tried to introduce tests to one of the team I worked at. I was somewhat successful in the end but it took some time and effort.

Basically, I made sure to work with the people interested in testing their code first. It's good to have other people selling testing instead of being the only voice claiming testing will solve ~~all~~ some problems.

Then I made examples: I tried to show that testing some code, believed to be untestable, was actually not that hard.

I was also very clear that testing everything was not the end goal, but, new projects especially, should try and leverage testing. Both as a way to allow for regression testing later on and to improve the design. After all, a test often is the first user of a feature. (This was for internal libraries, I expect it would be a harder sell for GUI where the end design might come from a non programmer such as a UX designer).

At this point, It was seen as a good measure to add a regression tests for most bugs found and fixed.

Also, starting from the high level, while harder (it's difficult to introduce reliable integration and end to end tests), usually yields benefits that are more obvious to most. People are much less nervous reworking a piece of code that has a testing harness, even if they are not in a habit of testing their code.

I did point at bugs that could have been easily prevented by a little bit of testing, without blaming anyone. Once the framework is in place and testing has already caught a couple of mistakes, it's much harder to defend the argument that time spent testing could be better spent elsewhere. And that's where we started to get discussions on the balance to strike between feature work and testing. It felt like a win.

It took two years to get to a point where most people would agree that testing has its uses and most new projects were making use of UT.

I like the idea of aggregating communities. Especially if the modding tools are powerful enough. This could lead to communities being essentially curated lists of other communities. Which is great for new users to discover new communities without being overwhelmed by the unordered list of communities on the instance.

Another feature that I'd like to see is an equivalent to the mastodon's lists, a way to aggregate communities for yourself. So that you could browse the content of communities sharing a same theme in a dedicated view.