kenmacd

My use case:

I used to use Arch. I would always do a btrfs-snapshot before doing a system upgrade, then create another one after booting the new update (provided everything worked). In NixOS I don't have to because it has generations. The upgrade is entirely atomic and if it doesn't work I just use a previous generation.

Second I used to use pyenv and bunch of other tools to make sure I had the right development dependencies. Instead I just put the requirements in a shell.nix or flake.nix in the project directory, have those called with direnv. Now I can easily have python38 with clang_11 for one project and python311 with gcc48 for another.

Third the system of modules generally makes it easy to have my system setup in one place, and with the services I want. If I want zram, I just set `zramSwap.enable = true;` and that works. If I need ssh access: `services.openssh.enable = true;`, oh, but I have the firewall enabled (networking.firewall.enable = true;), that's okay because services.openssh.openFirewall defaults to true, so it handled automatically. And if I change services.openssh.ports to a better port, the firewall will be updated too.

If I ask you what time it is and you're not really sure, do you say "It's 1:04:35.023"?

So if you 'said it was a lab leak', but expected people to know you really mean "based on the extremely limited information I have on the situation, it don't feel the possibly of it being a lab leak can not be entirely discounted", then you've communicated poorly.

You've said in this comment that "you thought it likely it was a lab leak". Again, that's not the words of someone with low confidence in their theory.

Then we have to come to your motives in espousing such a theory. What was your point in saying that then and now? Is it that you think the world in general should work towards better lab practices? If so why not say that instead. Why do you want people to know you think it was from a particular lab?

Just saying what you're saying sounds a lot like an anti-China dog-whistle, especially in the environment in which you're saying it.

To add to the other answer, if you calculate the absolute limit on performance for heating and cooling using the Carnot cycle, the 'heating' case is always going to be '1' higher than the cooling case, because you also get to use the 'work' heat.

He's located in NB, so I assumed it was Celsius. To check I just compared them to the Environment Canada data it seems to match pretty close for NB in Celsius.

I like his videos, but I don't trust his numbers in this one. He shows a COP of ~1 when it's 10 degrees out. These are the easiest possible conditions for the HP, and where all the specs show the highest COP. His graph showing the HP is running equal to a baseboard heater seems very suspect.

Seems rather short-sighted and unlikely to accomplish the authors goals. If we incentivize weight it seems we might end up with less safe batteries just because safer ones weigh just a little bit more. We could also lose efficiency and durability because running fewer batteries harder, or scrapping thermal management components, could reduce weight.

The Carnot limit of heat pump heating from -25C (-13F) to 20C (68F) is over 6.5. That's 650% efficient. There's a lot of heat in our 'cold' air. If you're going to try to claim 'thermal dynamics' [sic] you should at least do the math on it first:

1 / (1 - (248.15/293.15))

While they can have these elements, heat-pumps in general have come a long way in their ability to get heat out of the air at cold temperatures. Mine is still over 160% efficient at -13F, with no loss of capacity.

Below that it'll still operate at over 100% efficiency, but capacity starts to drop, so some part of the heating load may need to be made up by other means (it's common to install a handful of cheap resistive heaters for that case, as they add a redundant system that can continue to work even if the heat pump is out of service).

> So heat pumps will lower overall energy usage, but not peak usage.

This would only be true if we go far beyond normal 'cold climate' temperatures for a long period of time.

To get rebates in NS need to put a head per level. Also the systems can typically work a temperature sensor that's not in the unit. It can be in the remote or in a wired thermostat. This avoids the unit shutting off because the ceiling is hot.

Pretty sure this is sarcasm, but for general interest I'll mention the Phantom of Heilbronn (https://en.wikipedia.org/wiki/Phantom_of_Heilbronn), "responsible" for multiple murders, but really just an employee at the company that made the cotton swabs that got used for DNA collection.

>> <sigh> there's a lot of similar comments to this one.

> <sigh> and a lot of similar rebuttals to this one.

My point is that a lot of people don't seem to understand the 'why' of this issue and instead appeared to just jump to the conclusion that:

> It's exactly the same difficulty.

When that's not at all the case.

> using JS for client-side probing, and if Cloudflare is indeed injecting arbitrary JS into HTML pages it serves then that's utterly horrifying and is a problem in and of itself.

Well they are. From CF:

>> Cloudflare’s bot products include JavaScript detections via a lightweight, invisible code injection that honors Cloudflare’s strict privacy standards

But even before we consider that, if the request is for html then it's likely coming from a browser. If CF replaces that html with their own then the browser will likely run it allowing them to run all kinds of probes then run the redirect. The same is not true for a .txt file or an image.

No they couldn't. If you replace a .txt file with random html data bad things are going to happen.

Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt`

That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. What's the app going to think of that though?

<sigh> there's a lot of similar comments to this one. In short, it's much harder to protect a text file against DDoS. The ToS say 'a disproportionate percentage ... non-html' likely because they need to be able to apply their browser checks to clients.

Then CF replaces the html with their Browser Integrity Check. How does the app deal with the list becoming real 'Checking your browser" html?

You're looking at it backwards though. CF doesn't _actually_ care about what the content is, only that they can apply their DDoS protections to it. If you're serving a text file that's much more difficult as they can't replace it with their own content.

> Seems like if it were simply renamed to .html with no content changes, then it would be okay.

Imagine you do that and I DDoS the URL. CF will then mitigate this DDoS by, in part, replacing your html with their Browser Integrity Check html.

If you're serving 'web pages and websites' everything continues to work. What would happen if this list suddenly became an actual webpage.

If your site is serving 'a disproportionate percentage' of non-html you decrease the ability of CF to tell good traffic from bad.

Say you do that and I DDoS the easylist.html. Cloudflare will start applying their DDoS mitigation. Now everyone's app receives the Browser Integrity Check instead of the list.

Imagine you're trying to block a DDoS attack. If the client is downloading HTML then they likely also have JS enabled giving you a ton of options for running code on their computer to help you decide if the traffic is legitimate.

If they're downloading text you can still use the headers, and some tricks around redirects, but overall you have far less data on which to decide.

I used to love Weather Underground, but I stopped using them when they killed public API access. I get that they were trying to make money from products using their API, but they're making money on data from personal weather stations so at a minimum I would have liked to see a reasonably priced API plan.

My issue with this is that to access my own email I get countless warnings, and always have a 'You have recommended actions' Security Checkup for 'Remove risky access to your data'.

This is after jumping through a bunch of hoops to create a GCP app. It even complains about the pseudo-app being from an 'Unverified developer' despite that developer being me.

Yes it's local, but also can be taken away to run on a cluster. Looks like ssh-keygen is using 16 rounds of bcrypt_pbkdf. My laptop just took 185ms to try a password. So I guess I could run less than 10 passwords per second (per core?).

I don't keep an ssh key on disk though. I use my gpg key on my hardware security token, which gives you 3 attempts before you have to unblock it with a separate management password, which again you get 3 attempts at before the key is entirely locked.

But you add a password to the key, so it's the same.

And not everyone saves it to disk. My ssh key is my gpg key. It's stored on a yubikey and can't ever leave it. If I do a `git pull` then my yubikey flashes and I have to tap it to allow that connection to happen. Steal my yubikey, well you can't unlock it. Hack my laptop and you can't tap the key.

They didn't say they want something to go wrong, just that if it does Putin will blame someone else.

I expected this before they shipped models running Linux, but thought I was safe now. I've learned my lesson.

Here's a script that will set that mode, in case you'd like to use it. It prevents someone/malware from being able to use your key after you've unlocked it. For example if you hacked my computer and tried to use it to ssh to another machine you'd be unable because you'd need me to tap the key.

I'd suggest trying 'on' before 'fix', but then switching to 'fix' for the extra security it provides.

https://github.com/a-dma/yubitouch

Wow, I just tried it and found `gopass show -o ___` works perfectly to scripts that want just the password without any null bytes or newlines in it. You've converted me. Thank you for mentioning it, I never thought to look for a compatible drop-in.

Did you have our key on a yubikey and that yubikey set to require a touch for every operation?

You probably shouldn't be able to disable touch. If you can disable it then malware can disable it.

I'd highly recommend using the `fix` option instead of `on` to make sure it can't be disabled.

All great, but I wish `pass` was usable in scripts without having to pipe it through `head -n 1 | tr -d '\d'`