Recently posted comments

As for unmaintained dependencies, that is what why we have the RUSTSEC announcements about unmaintained libraries along with cargo-deny or similar tooling. Of course our method of detecting when a dependency is unmaintained could be improved here but that is inherently still better than pretending a large dependency is maintained when really the code base is 50% maintained and 50% code nobody looked at for years.

In the cfg80211 case, the user file operations are handled by queuing a work item that will then hold the wiphy mutex. However, if the debugfs file is removed before it runs, then the work item is simply cancelled so that the file removal can go ahead immediately.

It does not look to me like this API can easily be used for this debugfs use in cfg80211. That is probably fine, but it could still be an interesting usage scenario to look at.

Yes, it's all about enforcement. One of the "easiest" ways is to tie bonuses to the "little C++" percentage. You can also block releases until that percentage falls under some target thresholds - exactly like any other quality metric. You can also inflict more mandatory review, test coverage, process overhead and what not on that percentage - making life with the "little C++" miserable.

There are plenty of ways - use your imagination. But they all require a strong, top-down push from management. That push exists in some technical enough companies. That safety push could be enough to make Carbon successful - exactly like it's been making Rust successful.

Who employs the speaker BTW? :-)

Not sure what the exact extend of "regulated spheres" is but here at $BIGCORP there is definitely some amount of per-supplier work. How could the compliance process not care about the supplier at all?

> You don't get to avoid doing the paperwork for each unique type/size of screw by saying "they're all from The Phillips Screw Company"; you have to do paperwork for each unique type/size anyway

You can at least copy/paste the supplier information, that's much less work that researching 100 different suppliers.

Cheers,
Wol

It wasn't interesting to Universities? (So students never knew about it.)

Cheers,
Wol

That sounds like: a "good" language ought to make using raw pointers a "bad "experience in order to force developers to do things the (memory-safe) way you would prefer instead of the (unsafe) way that they would prefer.

Could not resist sorry (and thanks to excors https://lwn.net/Articles/1038755/)

In this day and age of massive supply chain attacks, things like "cargo vet" are critical. I have no idea whether "cargo vet" is the best solution and I don't even have a strong opinion on "massive dependency trees". But for sure there has to be _some_ sort of SBOM constraints to force most developers not to do things the way they prefer, which is: let AI write some code that imports random, orphaned open-source libraries and go home sooner.

(I hope no one replies with "Just train, police and manage your developers" which is the "mythical workplace" argument)

As to the CRL problem, I think an expired equine is being flogged. I think that end-to-end encryption is nearing the end of—or was abused beyond—its usefulness. The problem is that nearly the entire industry forces security verification to be performed on insecure systems; face it, Windows, Mac, Linux, BSD, Haiku and all other user-installed and -maintained systems are inherently insecure. Does anyone *really* expect a non-expert user to properly maintain the security of his own system?

The correct solution is OE (host-gateway/gateway-host/host-host encryption). It will be centrally managed (much like centralized IP address management). It will be managed much closer to home. If you can't trust your own gateway, you might as well unplug all of your systems and return to pencil and paper.

In short, it comes down to trusting a far-off, nameless, faceless 'authority' to do the right thing. I don't know about any of you all, but I would far more readily trust the local expert in my home or in my neighborhood with whom I can speak face-to-face than the large, central, all-controlling national government or a self-publicized charlatan expert half-way around the planet. End-to-end encryption that depends on far-away people who are more concerned about profit than security is a losing proposition. End-to-end encryption should be reserved solely for situations that truly require it, such as banking, voting, and site-to-site VPNs.

In all other error messages TeX's error messages consist of two lines. The first line has the line number and all characters that are read up to the error, the second line has the characters that are still to be processed.

But that is actually a bynote. You wrote

> tagged pdf or other niche features

Since journals (especial scientific journals that Lee wrote about) and other publishers increasingly demand the production of barrier free PDFs for online publication, Tagged PDF is not a niche feature, IMNSHO. Customers of mine currently pour 6-digit numbers of Euro in creation of such files. For private production it doesn't matter -- but for publication, it will soon be a must-have.

Maybe this could become a standard for communicating with firmwares too, so drivers don't have to keep re-inventing this wheel?

It's quite different because it's heterogeneous (both at the HW and SW levels) but most systems are _already_ "multi-kernels" when you think about it!

Similar stuff before has been called "Logical Partitions" (LPARs) by IBM, and "Logical Domains" (LDOMs) by Sun Microsystems (the sun4v stuff introduced in UltraSPARC T1 Niagara).