theothershoe (u/theothershoe)

theothershoe commented on Hyundai’s future EVs will also have Tesla’s EV charging port theverge.com/2023/10/5/23... · Posted by u/mfiguiere

Armisael16 · 2 years ago

NACS already uses the CCS signaling protocol, and always has - Teslas have been able to use a dumb adapter to plug into CCS chargers for years.

theothershoe · 2 years ago

Oh, interesting! I'm not the most up-to-date on this, but I don't think I was all wrong about what I said. My understanding is that cars with CCS adapters currently cannot use Tesla chargers (except the Magic Dock ones), but Tesla now says they will change the signaling so that soon CCS cars will be able to use Tesla chargers with an adapter.

One of my sources is, https://www.cnet.com/home/tesla-superchargers-will-soon-work...

AFAICT "NACS" is a new thing as of November 2022. Maybe it's basically a renaming of Tesla's existing thing. But the shift to NACS includes important details around published specs and interoperability.

theothershoe commented on Hyundai’s future EVs will also have Tesla’s EV charging port theverge.com/2023/10/5/23... · Posted by u/mfiguiere

tegmark · 2 years ago

it was so annoying to suffer the fools who loudly complained about tesla roadblocking a universal charger while ignoring the fact that NACS was way better than the alternatives

theothershoe · 2 years ago

Tesla's charger was proprietary so other manufacturers couldn't use it. Meanwhile CCS is an open standard that anyone can use.

What's changed is that last year Tesla decided to publish an open standard. Now that other manufacturers can use the plug, they gave agreed to use Tesla's physical plug design, but with the CCS signaling protocol.

So NACS going forward is more of a new hybrid of the two rather than a switch to Tesla's existing charger. One of the outcomes is that cars equipped with CCS will be able to use NACS with a simple adapter.

Why not use Tesla's signaling protocol? I don't know the details. Maybe Tesla isn't ready or able to create an open standard for that part. Or maybe other manufacturers want to keep the signalling they have to keep adapters simple. In any case only one vehicle and charging station manufacturer (Tesla) will have to make updates on the software side, and to people who don't know the difference between the plug and the software it'll look like Tesla won the charger war.

theothershoe commented on Twitter / X is losing daily active users. CEO Linda Yaccarino confirmed it mashable.com/article/twit... · Posted by u/thunderbong

theothershoe · 2 years ago

Just in case you're not aware, Soros conspiracy theories are a dog whistle for the less-publicly-acceptable "jews control the world" conspiracy theory. Of course it's not racist to criticize a specific person for specific actions. But that's not what the vast conspiracy theories around Soros are. Whether or not you are acting in good faith, you are repeating antisemitism (maybe unknowingly) when you bring this stuff up.

theothershoe commented on Show HN: FlakeHub – Discover and publish Nix flakes flakehub.com/... · Posted by u/grhmc

trulyrandom · 3 years ago

I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time.

In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)

theothershoe · 3 years ago

As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime.

I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.

theothershoe commented on Introducing Hooks reactjs.org/docs/hooks-in... · Posted by u/sophiebits

theothershoe · 7 years ago

On the positive side hooks provide a lot of options for declarative abstractions. I expect that to a large extent the built-in hooks will be used as building blocks for new libraries. I think it is likely that this will outweigh the negatives.

On the other hand, hooks rely on hidden side effects so that each hook invocation returns something different depending on which component instance in the component tree is being rendered when the hook is called, and the number of times the hook has already been called while rendering that instance. This introduces semantics that are unlike anything I know of in the language. A redditor, u/hardwaregeek, pointed out that hooks behave kinda like a state monad, albeit emulated with imperative side-effects.

theothershoe commented on The Makefile I use with JavaScript projects olioapps.com/blog/the-los... · Posted by u/theothershoe

jlg23 · 8 years ago

The author forgot some great features of make:

* Parallel execution of build rules comes for free in a lot of implementations. This is really noticeable when you do heavy asset pre-processing.

* Cleanly written build rules are re-usable across projects as long as those projects have the same structure (directory layout).

* Cleanly written build rules provide incremental compilation/assembly for free: You express intermediate steps as targets and those are "cached". I put the "cached" in quotes here, because you essentially define a target file which is regenerated when it's dependencies are updated. Additional benefit: Inspection of intermediate results is easy - they are sitting there as files right in your build's output tree.

theothershoe · 8 years ago

Thank you for these points! I think that parallel execution is especially appealing. I edited the article to mention that.

theothershoe commented on The Makefile I use with JavaScript projects olioapps.com/blog/the-los... · Posted by u/theothershoe

jerf · 8 years ago

"In all seriousness, what's wrong with it?"

1. Claiming a rule makes a target, but then fails to make that target, ought to be a runtime fatal error in the makefile. I can hardly even guess at how much time this one change alone would have saved people.

2. String concatenation as the fundamental composition method is a cute hack for the 1970s... no sarcasm, it really is... but there's better known ways to make "templates" nowadays. It's hard to debug template-based code, it's hard to build a non-trivial system without templates.

3. Debugging makefiles is made much more difficult than necessary by make's default expansion of every target to about 30 different extensions for specific C-based tools (many of which nobody uses anymore), so make -d output is really hard to use. Technically once you learn to read the output it tends to have all the details you need to figure out what's going wrong, but it is simply buried in piles of files that have never and will never be found in my project.

4. The distinction between runtime variables and template-time variables is really difficult and annoying.

5. I have read the description of what INTERMEDIATE does at least a dozen times and I still don't really get it. I'm pretty sure it's basically a hack on the fact the underlying model isn't rich enough to do what people want.

6. Sort of related to 2, but the only datatype being strings makes a lot of things harder than it needs to be.

7. Make really needs a debugger so I can step through the build, see the final expansions of templates and commands, etc. It's a great example of a place where printf debugging can be very difficult to make work, but it's your only choice.

That said, I'd sort of like "a fixed-up make" myself, but there's an effect I wish I had a name for where new techs that are merely improvements on an old one almost never succeed, as if they are overshadowed by the original. Make++ is probably impossible to get anybody to buy in to, so if you don't want make you pretty much have to make something substantially different just to get people to look at you at all.

Also, obviously, many of the preceding comments still apply to a lot of other build tools, too.

theothershoe · 8 years ago

I'm happy to see this kind of detailed criticism. I would be happy to use a new tool if it is similarly general, and has a declarative style. Other commenters brought up Bazel, which I am looking forward to learning about.

theothershoe commented on The Makefile I use with JavaScript projects olioapps.com/blog/the-los... · Posted by u/theothershoe

aidenn0 · 8 years ago

This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh

theothershoe · 8 years ago

I have been meaning to spend some time with redo!

https://cr.yp.to/redo.html