achamayou

Is that really true with limited imports though, and/or with precompiled bytecode?

I was surprised to find that Ubuntu’s handler for unknown commands that tries to suggest what you could apt install is written in Python. I’ve never noticed it being slow.

Microsoft's new strategy has not happened to the detriment of quarterly numbers, on the contrary.

Microsoft does exactly that, they're called Secure Access Workstations, and they're used for all sensitive work. You can find some details here: https://docs.microsoft.com/en-us/windows-server/identity/sec...

They're described as PAWs in the document, but they are called SAWs internally (as one of the notes explains down the page).

But it's not widely available from cloud providers at the moment, particularly if you want meaningful remote attestation to work.

They vastly exaggerate their popularity, helped by the lack of publicly available information. The number of quants writing q is dwarfed by those writing Python, Scala or even Slang.

First Derivatives’ revenue last FY was ~200m and their pre-tax profit is ~17m. To say that they are unaccountably popular on the Street is quite an overstatement.

No they don't, GS strats have overwhelmingly used Slang/SecDB for many years now.

French here, I absolutely agree. Specifically, American English would be preferable because it is what’s spoken widely outside Europe, and its spelling is somewhat more regular (as well as historically accurate!).

I wonder to what extent coming up with a new name for it would help adoption.

Nothing gets increased unless you think her customers just wouldn’t shop at all if it wasn’t for her, or would somehow do so in perfectly safe and carbon-neutral ways.

Our team has been using remote VS Code to build our project on Azure Confidential Compute VMs. The tool is amazing, and is a massive improvement over all other remote dev solutions we’ve tried. Thank you!

It would be nice to integrate the context functionality into https://github.com/Qix-/better-exceptions

Depends, it might also be a feature if you suspect people under-report their drinking. Your non-drinking group may in fact be drinking just as much as your moderate drinking group.

I’ve used mermaid for documentation, through plugins for mkdocs and Sphinx. What’s great about it is that the diagrams are stored as readable source text in the documentation, which is easy to diff and modify along with the rest of the doc (search and replace when renaming a component etc).

That’s a huge benefit compared to storing rendered bitmaps, with a source file next to them. There’s much more friction involved in keeping those up to date, the changes don’t display usefully in PRs etc. They’re almost never up to date as a result.

Another thing mermaid lets you easily do is generate sequence diagrams from code such as testcases, because the format is so simple and line-driven. The outpout can also be included in documentation as samples, and is guaranteed to be up-to-date.

But they will be knowledgeable in something that is only tangentially related to systems programming.

You are potentially missing out on a lot of talented systems programmers who are not willing or able to put up with terrible build and packaging infra and therefore stick to another domain.

As for motivation, you are also missing out on anyone who has a small contribution to make but isn’t willing to dedicate hours trawling through Makefiles. That doesn’t seem good either?

Dealing with unnecessary build and packaging complications, often dictated by legacy constraints, is a distraction for a systems programmer and does nothing for the quality of the software itself.

I used to get my supplies from Fermier [1]. Excellent but quite expensive.

[1] https://www.fermier.co.jp/c/shop_atago.php

100% means nothing, but 30% means something is wrong. Coverage tells you nothing, but the absence of coverage is interesting and useful.

But if someone gets a bulb from your bins that you’ve thrown away because it was defective in some way, and gets access to your WiFi that way, it’s a bit annoying.

Thank you!

So you have any links? I’m very curious, and a quick search did not turn up anything.

As a counterpoint to that, another change happening in the industry now is the increasing tendency to delegate more and more to ML models, which are even less amenable to formal verification than mainstream PLs.

Best start wearing white gloves then!

Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).

There are a bazillion of Bluetooth receivers out there, Google neither invented those nor was particularly good at making them.

It is possible to do redefine NaN as something different than what IEEE 754 contains, but it will surprising to some users, and it will come at a performance cost because you can no longer let the hardware handle all float comparisons directly.

No, because x < NaN and x > NaN are false for any value of x.

But the flip side may be that since it is lighter than « legal punishment », individuals don’t benefit from the same due process and recourses they otherwise have.

Sure, sometimes someone with the ability to do so needs to make a call and decide if the issue is to be treated as a bug or a feature request. It does not follow from it that planning and bug tracking are the same thing and are best done with the same tools.

Work tracking is also not the same as bug tracking (or planning!), and it is not obvious that all “work” meaningfully goes into the same queue. A dev lead with a basic grasp of context switching costs and specialised knowledge will instead look at several streams and organise accordingly.

It absolutely makes sense to keep planning separate, if for no other reason than the planning process and details rarely benefit from being exposed directly to the users. Bug reporting and fixing on the other hand is at its best when it is fully open, and is a valuable resource for users.

A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.

A good bug entry is (completely) unlike a project planning entry. It comes with detailed environment and repro instructions, artefacts such as logs and screenshots. It’s an investigation, not an item in a wish list, and it’s ideally a place where every dev in the team can chip in and offer additional data or suggestions.

If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example. Bugs are either open or fixed!

The tool does not figure out who should be fixing which bug, that’s the job of the team lead.

When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature).

A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed. Cluttering that with project management does not help!

What gets measured gets done. If closing lots of tickets is seen as productive, you not only get lots of very granular tickets, but all sorts of grouping tickets and epics as well!