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 don’t think that’s the issue. As said in the article, the researchers found the flaw by reading the architecture documentation. So the flaw is in the design of the API the operating system uses to configure the CPU and related resources. This API is public (though not open source) as to allow operating system vendors to do their job. It usually comes with examples and pseudo code on how some operations work. Here is an example (PDF).

Knowing how this feature is actually implemented in hardware (if the hardware was open source) would not have helped much. I would argue you are one level too low to properly understand the consequences of the implementation.

By the vague description in the article it actually looks like a meltdown or specter like issue where some code gets executed with the inappropriate privileges. Such issues are inherent to complex designs and no amount of open-source will save you there. We need a cultural and maybe a paradigm shift on how we design CPU to fully address those issues.

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.

This looks like one of those wireguard based solution like tailscale or netbird though I’m not sure they are using it here. They all use a public relay used for NAT penetration as well as client discovery and in some instance, when NAT pen fails, traffic relay. From the usage, this seems to be the case here as well:

Share the local Minecraft server:

$ holesail --live 25565 --connector “holesailMCServer420”

On other computer(s):

$ holesail “holesailMCServer420”

So this would register a “holesailMCServer420” on their relay server. The clients could then join this network just by knowing its name and the relay will help then reach the host of the Minecraft server. I’m just extrapolating from the above commands though. They could be using DHT for client discovery. But I expect they’d need some form of relay for NAT pen at the very least.

As for exposing your local network securely, wireguard based solution allow you to change the routing table of the peers as well as the DNS server used to be able to assign domain name to IPs only reachable from within another local network. In this instance, it works very much like a VPN except that the connection to the VPN gateway is done through a P2P protocol rather than trough a service directly exposed to the internet.

Though in the instance of holesail, I have heavy doubts about “securely” as no authentication seems required to join a network: you just need to know its name. And there is no indication that choosing a fully random name is enough.

On the topic of exposing sequence number in APIs, this has been a security issue in the past. Here is one I remember: https://www.reuters.com/article/us-cyber-travel-idUSKBN14G1I6/

From the article:

Two of the three big booking systems - Amadeus and Travelport - assign booking codes sequentially, making brute-force computer guesswork easier. Of the three, Amadeus, through its web portal CheckMyTrip, is especially vulnerable, Nohl said.

The PNRs (flight booking code) have many more security issues, but at least nowadays, their sequential aspect should no longer be exposed.

So that’s one more reason to be careful when exposing DB id in APIs, even if converted to a natural looking key or at least something easier to remember.

This is what was used by Benjamin to fix David’s issue with his XPPen stylus. Here is the mail thread where this was discussed.

It’s nice to see it documented now. Hopefully this will extend the support of weird devices such as tablets and game controllers since it should allow user space to “fix” them.

Ah, I see. I think you might need to specify your own pre-scaled texture for those then. By creating a StyleBoxTexture, as many as needed for all the disabled/hover/normal/… effects and use those in your theme. Which is not ideal, but that's all I have.

Otherwise, if you want to automatically scale your UI, you can have a look at the viewport suggestion from @magikmw and make an auto-loading node that does the necessary manipulations for you. Though it will scale everything, font and icon included.

If you are working with vector font, you can set some global settings that should help.

In Project Settings, tick Advanced Settings and then look for:

General -> Rendering -> Textures -> Canvas Textures -> Default Texture Filter: set to Nearest

General -> GUI -> Theme -> Default Theme Scale: set to the appropriate value, e.g., 4

Note that in this same panel you can set the default theme to your own. Then, as suggested, reload the project for the changes to apply.

If you are working with bitmap fonts, then yes, you have to manually scale the root Control node of all your scenes, while still enabling the texture filter to nearest. But there should be few of them hopefully.

Though, I'm not an expert, so there might be a better way.

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.

I disagree. The question is not really “should we give programmer more power at the cost of yet another UB” but more “should we grow the API and add another UB for the select few for whom it might matter”. When you consider choices made on other parts of the STL, such as std::unordered_map, then you realize the STL is not about being the most performant things around, but rather a collection of reliable tools covering basic usage for 80% of the user base.

With that in mind, I am against adding yet another function, which has its pitfalls, for minimal benefits. Again, such a function would be made almost entirely obsolete by a safe function that works with iterators/generators of known sizes. So I see even less benefit in adding a function that will just become yet another liability down the line.

The benchmark looks off. The msvc one may be the only one vaguely reliable. I suspect clang and GCC were able to optimize the synthetic benchmark to a little more than a loop doing additions. At 96ns for 1000 iteration, you are looking at 10G iterations per seconds. Which can only be achieved by a loop of two instructions executing at 2 inst/s on a 5GHz processor. And you will not get a 5x just for removing a highly predictable branch.

So yes, std::vector leaves performance on the table, but no more than 10~15% for trivial loops that are not that uncommon but are rarely a bottleneck.

Then you have to ask yourself, is it worth it to add yet another function that can crash your program if misused just for that 10% in a situation where they might not even matter. I mean, I know, it’s c++, zero cost abstraction, yadi yada, but if you’re looking for consistent performance you should have moved away from the STL already. As this post shows, your STL vendor already has a huge impact on the performance, and there are widely available options to optimize specific cases.

So I’d rather keep the STL fairly simple. Add one function to work well with generators/iterators that have a known size if you want, but adding unchecked versions of every insertion function of every STL container is not worth it IMO.

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.