A shame it doesn't use udsoncan as a backend. Udsoncan is pretty well done and indirectly support doip which is going to be ubiquitous in those new software defined vehicles..

For an application that is limited to stadardize services doip will only matter for future EVs. Anything with ICE will continue to provide data on CAN.

MIT is not a gift. It still requires attribution, notice and license term.

This lawsuit is even not about copy left.

so? the gist of the mit license is, "use without restriction". without the license the default is that you have no right to the work, so the license is what makes it a gift. you're welcome

no it very much isn't use without restriction - you must credit the the author and otherwise follow the licensee. I can't copy and republish code from the Nvidia driver leaks because those are copyrighted by Nvidia (unless I have permission from them). In the same way you cannot copy and republish code from a MIT project unless I have permission from them (via the MIT licensee).

i would suggest reading the text [0] to educate yourself

[0] https://opensource.org/licenses/MIT

I would suggest to read the text and then contribute to the discussion. We have access to search engines too.

But doesn't it say:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

So that's a required attribution if you want to follow the MIT license?

Another key reason to me that open source can be very good quality is when the developer is the key user.

If the developer has strong knowledge of the business while designing a product, it always ends up with better qa as they are writing the right product on first draft.

You hardly get that when you hire someone to do something for you. That is valid in other domain than programming.

Very helpful! Thanks!

What could be missing is the GPU aspect. Not sure if the data is available, but it is very unclear to me which GPU is available on which machine type. and also how many, so that I have some chance to get one.

In the Instance Picker in the "More" section you can find the GPU Filter. Additional GPUs can only be assigned to N1 and A2 instances. The whole Accelerator topic is very specific. Maybe I will expand it further if more people find it helpful.

cool. It was hard to find. :)

looks like only a100 accelerator is documented.

cannot find any info about P4, T4 or P100

Wordle will become the new todolist

Looks like QuickTransit was a jit engine which was the base of Rosetta 1. Rosetta 2 is AOT translation.

They’re both based on QuickTransit, but Rosetta 2 has an AOT mode as well as JIT. I’m sure the R2 engine is more advanced than the original engine, Apple employed several engineers from the original team, but it still uses and is based on licensed tech.

My understanding is that Rosetta 2 is based on LLVM.

Even the company that made QuickTransit is gone now, having been bought out by IBM a decade ago.

My understanding is that Apple hired a lot of the staff of Transitive, and had a more or less do whatever you want license with source access. Ad that the AOT mode is based on LLVM, but the JIT piece is still pretty core to the design (hence why other JITs run well on top of it).

It’s not based on LLVM, that’s way too heavy for the use case.

The same backend is used for AoT and JIT compilation. It uses a custom lightweight IR that’s really close to x86 itself, with a big focus towards reducing translation times.

Rosetta 2/Cambria was fully written in-house.

It looks like websocket+msgpack would have similar overhead once the initial initial overheard is passed.

But you won't miss all the http reverse proxy ecosystem.

Good ol times when front page videos were 40k views max...

Can you elaborate? This does not make sense to me

See LGPL v2.1 section 7. It's annoying to comply with. Section 6 too. 7a was clearly designed for proprietary software. It would be a problem with the GPL too if section 3 wasn't there.

LGPL v3 didn't make things better.

Python ambee is a simple client library for a proprietary sass iot service. I guess they want to control exactly how their users are using their service.

Yet the author is an admin on the HomeAssistant community forum, one of only 6. Presumably his other contributions to the project justify those privileges, and he did not shut down the passive-aggressive thread some nixOs folks started there, it was another admin (the founder of HomeAssistant).

This sucks for nixOs, but it looks like community incompatibility means they won’t be able to support HomeAssistant at all.

Some context: Frenck is a core developer on the Home Assistant project, and was hired by Nabu Casa (the company the project's founder founded to try to create a sustainable funding source via adding some optional value-add services) to develop for Home Assistant full time.

If instead of packing these separately, the home assistant nixpkg for home assistant simply downloaded all the required dependencies from PyPi, and verified them against a maintained list of checksums as part of the nixpkg (for reproducibility), then frenck probably would not object to that, since the last I knew the some of the official home assistant docker images do preinstall the requirements for the majority of plugins like that.

I'm suspect frenck's real concern comes from any possibility of modifications in the packaged version, combined with any possibility of nix allowing home assistant to be used with a version that is not an exact match of what home assistant specifies.

Alternatively If this could be packages as some form of home-assistant sub-package that was guaranteed to always match the PyPi version specified for home assistant exactly, without any mixing and matching, it would likely allay his concerns. Unfortunately he has not spelled out his concerns fully, so I cannot know for sure. I also have no idea if this is at all feasible in the nix packaging system.

> If instead of packing these separately, the home assistant nixpkg for home assistant simply downloaded all the required dependencies from PyPi, and verified them against a maintained list of checksums as part of the nixpkg (for reproducibility), then frenck probably would not object to that

From what I can tell the Home assistant core team doesn't not want to deal with any other installation variants than their own supported ones. Their user base consists of a lot of technical tinkering people (hobbyists, electricians, etc) but those who don't necessarily have Linux sysadmin skill's. So you could say they are skilled enough to get themselves in any of a hundred different configuration scenario's that would then need to be debugged by the HA developers for each support ticket. For a developer knowing the installation environment is at least sane is a great help.

That said, Home assistant does lend a lot of its growth to open source contributions, collaboration and being free software. If it was not as open in the beginning it might not have gathered enough attention to grow its current size. Cutting off developments in other directions like this to me feels against what FOSS stands for.