capitol_

Split DNS causes lots headaches, it also makes it really hard to root cause analysis of failures when they involve DNS.

Intel: https://en.m.wikipedia.org/wiki/Intel_Management_Engine

Amd: https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...

Lets hope that zig becomes a memory-safe language before 1.0 then.

"UB only if the hardware doesn't like it" sounds like you want to shift the complexity from the developers who know the problem domain best to the packagers.

As soon as the thing is packaged to run on an raspberry or something else that doesn't like it, it will start to generate CVEs and be a major pain.

The case-sensitivity algorithm needs a locale as input in order to correctly calculate the case conversion rules.

The most common example is probably that i (U+0069 LATIN SMALL LETTER I) and I (U+0049 LATIN CAPITAL LETTER I) transform into each other in most locales, but not all. In locales az and tr (the Turkic languages), i uppercases to İ (U+0130 LATIN CAPITAL LETTER I WITH DOT ABOVE), and I lowercases to ı (U+0131 LATIN SMALL LETTER DOTLESS I).

case-insensitive is all fine if you only handle text that consist of A-Za-z, but as soon as you want to write software that works for all languages it becomes a mess.

I would love to have these effects as an option when viewing man pages.

It would easy fit in ram: https://yourdatafitsinram.net/

An important aspect/variant of this is that it's better to do nothing than fill your time with low quality distractions.

By scrolling low signal/noise content we block ourselves from this fenomena.

What programming language do you use where there isn't performant hashing/compression algorithms implemented as libraries?

That just sounds like a bunch of api's on top of linux.

BMI measurements do have some signal for endurance athletes.

People who win running competitions are quite tightly grouped BMI-wise.

And for running I guess that makes sense, a kg of muscle weights as much as a kg of fat. Even if that kg of muscle is a lot healthier than the kg of fat.

But would that really be faster when you need to read every byte of a file?

I thought memory mapping solved a different problem.

There is also a time aspect to the equation.

The goal is to improve wages and conditions for workers in a sustainable way so that the improvements are guaranteed to persist over time and not be a one time thing.

Basically it's important to not lose the war by winning one battle.

That could be a long play from the employer side to disincentivize the workers from joining forming/joining a union.

This is why I really like Debians policy of being self-contained, that everything in Debian is built from sources that are in the Debian system.

It takes a lot more effort to package stuff, since you can't just download your dependencies from the internet. But you also create something that isn't as ephemeral.

It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.

The notion/mindset that "This tool can only be used if you are good enough" is an enormous design smell in my opinion.

Tooling exist to help you and your team do the required work as good or fast as possible.

If you are using tools to gate keep juniors in your field, or that are unnecessary complex in order to stroke your own ego. Then the tool is more of a weapon against the rest of your organisation instead of something helpful.

This is interesting, do you know where I can look at the numbers for this?

My gut feeling was that the realistic way to handle car emissions will be to migrate the global car pool to electrical, but I don't have any hard number to back this gut feeling with.

In my packaging work I encounter hard coded assumptions about pointer width, endianness and presence of atomic operations.

They use that at work on some of the freeze seating places.

It's quote buggy and resource hungry on macos and didn't play nice at all on my Ubuntu.

Debian only ships free software (in main, but that's a detail).

This is actually enforced and there is processes in place to ensure that it stays that way.

This means that all new software that Debian packages is audited by a group of volunteers, the ftp-masters team, they check copyright, license and stuff like that.

If all binaries in Debian would vendor all of their dependencies, this would cause a lot extra and duplicated work for the ftp-masters, a team that already have a lot to do.

Same with security, if a popular go library needs to be patched to fix a security problem, then it's easier to do that in one place instead of patching it in N different binary packages.

Aha, yes, the business ethics 'it's only illegal if you get caught' that gave us Elizabeth Holmes and similar.

This demonstrates why the Schrems II judgement was so important.

But people who write criticisms provide a valuable service to me as an consumer.

I have limited amount of time and before I spend 20 hours on a book or game I would like some indication that it's not a waste of time.

One could argue that both the good and the bad should be highlighted, but my experience is that I'm get most value from knowing about the bad parts.

This is a pretty sad state of affairs.

* There is no namespaces, so all internal packages must be individually protected * It's easy to misconfigure the various python package tools to open you up to dependency confusion attacks * The only effective protection mechanism that you can implement across a large enterprise fills the index with spam and is forbidden

It would really improve things if they could introduce namespaces and let legal entities own those.

That is true, but let me quote from further up in the thread:

> Just because an attack may be niche it doesn't mean that the vulnerability should be ignored

GDPR to the rescue, send a delete request.

Wouldn't that require that the complete boot chain is totally locked down and cryptographically secure?

If you can insert a usb-plug and boot from that you could unlock the disk with the help of the tpm, or interrupt grub and set init=/bin/bash.

Or since the scenario is that the attacker have physical access, maybe desolder the tpm chip and move it to another computer where they have control over how the machine boots.

I guess modern gaming consoles are locked down in such a way so that this makes sense, but I have never seen a general purpose computer secured like this.

Thanks for explaining, I guess the above was mostly my stream of consciousness ranting.

I have never understood what threat scenario this is meant to protect against.

That a thief opens your laptop and steal the harddrive instead of the complete machine?

Or is this just a solution that is meant to check a checkbox to make an auditor happy?

It's hard to send stuff over the Internet without exposing some personal information, like your ip number.

I guess they might send it over TOR to get around that.