

Are the common-controls determined per user?
If yes, that would be awesome.


Are the common-controls determined per user?
If yes, that would be awesome.


Not as far as I’m aware of. You can kinda fake it with references like you would in C++.
With all the missing context it would also be possible that the author is trying to track invalid whatevers and the invalid flag is actually wanted state.


We are missing a lot of context but strong type systems give you the superpower to make unwanted state unrepresentable:
Here we can see the class member invalid being used as a flag to express that this method didn’t work out as expected. It is very easy for someone else down the line to ignore/forget (/never even knew about it) to check that invalid flag and just use the result regardless, which will likely lead to more failures later on.
Instead the author should directly return something that indicates invalidness. This could be as simple as returning a boolean or especially if this is a constructor it would be better to throw an error.
That way the invalid class never even gets instantiated and is therefore impossible to misuse. All validated by the type system.


Like you already hinted at batteries are DC systems and can only be charged using DC. Many EVs have at least a small AC to DC converter on board. When you plug it into an AC source the charging speed is limited by the size of that converter.
DC charging stations bring their own converters which are oftentimes much more powerful and therefore heavier than what your car carries along.
Whether you use an external 19kW converter or your cars internal converter doesn’t make a difference. In both cases the cars charging circuitry will monitor for dangerous situations such as overheating and throttle the charger down if need be.
The important question is how large your cars converter actually is. Sure the L2 charger provides 19kW AC but can your car’s converter actually use all of that?
If it can only do 10-15-ish kW then it’ll charge slower and therefore won’t tax the battery as much as a DC charger with 19kW would.
I don’t know what car this is and how PHEVs play into this but existing BEVs have been charging with much higher speeds for more than 100,000 miles and generally don’t end up with broken batteries.
Depends a lot on the make and model of course, as I’m sure there are some horrible examples out there. But the public fast chargers wouldn’t be under such demand if it was that damaging to the cars.


The flying craftsman really needed to get to that rest area
Not just on the web. I’ve previously used it to embed a short clip in a presentation.
The nice thing is that it doesn’t do a massive screencap but only captures the text. This way the replay will be freshly rendered at native resolution.


Thank you for this excellent explanation.
I knew that they could dock two dragons but the video’s framing appeared to intentionally highlight the dragon in question.


Wouldn’t it be much more efficient to have the trunk face retrograde?
The video appears to show a radial in burn.


Now just dont bonk them on the way out the door


Stuffing batteries into the cardan tunnel was a stupid idea. If you want your EV to have any range you need to design the chassis from the ground up for that purpose. You know just like they did for the Golf with an ICE engine.
I’m not against a refreshed EV Golf but that earlier concept wasn’t the best implementation.


My motivation for using NixOS is maintenance. I’ve been running 2-3 personal Linux computers for the last decade, with one of them being a server.
To get stuff like services working with each other you sometimes need to make small changes to the config files of some services. The issue for me especially with the many services running on the server is coming back to a broken/misbehaving machine after 4+ months and now having to research what changes I made long ago and where those config files are buried.
Making the change and testing it would likely take less than 5 minutes if you had every detail you need fresh on your mind.
I simply don’t have the mental capacity to remember all that stuff after months of working on other things. Especially if you’re coming back to something broken this is a really annoying position to be in.
You want the fix now but have to start by looking up docs and trying to figure out what past-self did to get you into this mess, or to find out what has changed since then.
At some point I had enough and was either going to teach myself some sort of personal changelog / documentation system, or learn a new declarative configuration system.
Huge respect for anyone who can keep all this info in their mind and to those that meticulously update their own documentation, but I lack the discipline to do so in the heat of battle and will easily miss things.
Since then any system that I will have to maintain myself has been using some form of declarative management. It keeps all configuration accessible and organized in one place, so I don’t have to go digging for the correct file paths. It self updates so that even when I go back and forth during testing I won’t miss updating my standalone docs.
And NixOS brings this to my whole system. No old programs lying around because you forgot to uninstall them and have now forgotten about it. Same thing with pinned package versions that then wreak havoc once they’re incompatible with the updated rest of the system. It even configures my goto tools (shell, editors, etc) to my personal liking when I set up a new machine.
Its not the first declarative system and probably won’t be the last one I will use, but for now it really makes my life noticeably easier.


I get that this seems very intimating, but if you’ve ever used more than three programming languages in your life, I believe you won’t have much to learn.
I can mimic the syntax and I very roughly understand how the import system works. But I don’t know Nix! Yet I haven’t had any trouble language wise over the last few years.
In my experience most of the “code” you write is package names and those can be copied from search.nixos.org.
In that sense I’m effectively using it as a markup language and I don’t think anyone has ever gotten discouraged by having to “learn” YAML, just so they can write a config file for some piece of software they want to use.
Something that I would take as discouragement is the state of the documentation. It has been improving to a usable level in some areas but other areas are heavily outdated or just plain missing.


This time there was an accompanying explosion in the skirt. Fun times
Hoping to get a piece of that fish


deleted by creator


Just want to add that my GTX 1080 runs Rimworld on the highest settings in 1440p without breaking a sweat.
It should however be noted that the drivers for it are now in maintenance only support mode. That by itself isnt really a problem, but NVIDIA will likely drop all support in a couple of years, if not earlier.
I fully agree with the rest of your recommendations. AM5 is a very versatile platform.
Bezüglich des Pfostentexts: Eine “Break” ist das nur wenn du sie nicht benutzt.


Thanks for the heads up. I have an ESPHome device with a display where I’ve replicated the HA look and feel. Guess I’ll have to update that now


While I fully agree with the opt-in sentiment, 95% of all core integrations are likely “inactive bloatware” on your instance, yet I don’t see anyone complaining about that.
Last time I checked we were at around 1500 core integrations on the search page.
How much is the fish?