Hacker Newsnew | past | comments | ask | show | jobs | submit | treffer's commentslogin

That they would never see me buying again from them. That I can stop OTA. That matter is interoperable and I can run multiple gateways before cutting them out.

Most IoT stuff I own had a good track record. The only stuff that screwed me over was the logitech harmony smart remote.

But I usually pick the more open ecosystems and vendors. E.g.heating is on shelly.


If we start from GP premises where they were multi-vendor on ZigBee and now (allegedly) are living a much better mono-vendor life with Matter, you cannot play the multi-vendors card. I'm on ZigBee multi-vendor orchestrated by Zigbee2MQTT and while some devices are quirky sometimes (worse offender... IKEA) I'm not planning to move over to Matter any time soon at all.


Modern wifi has always been a killer for OpenWRT. Usually expect to be 1 gen behind for a few years.

I wanted Wifi 7e recently (upgraded to really fast fiber) and went with Ubiquity for that.

I did find the Totolink X5000R extremely good. 50€, WiFi 6 on both bands, fast. But I couldn't find a 7e upgrade I would be happy with.


RedHat used to have a poster of the linux source code. Because some early version did fit a large sheet of paper.

Not sure if that's still available but it was a fun poster that I can highly recommend.


Or switch to HDR if you have a capable display.

I was pleasantly surprised that HDR also means you can control brightness - it is all software I that case!

And the brightness keys on an external Apple keyboard work.


According to my (limited) testing, you can only control brightness when the transfer function used on the HDR content you see is HLG. When it is PQ, the luminance seems to be “absolute” and ignores the display’s brightness settings.


I pre-ordered because I loved the Pebble Round - especially the size and look. My intended use case is for formal dress codes and special events (weddings, new years, ...) wheretny fennix 51mm does not fit in (literally and figuratively).

That said: I can't find full dimensions for the new round 2. I can guesstimate that it should be 10-20% smaller in diameter and less than 2/3 the thickness.

Would you mind sharing full dimensions or even update the post?

And congratulations! I really like this. I hope there will be enough of a market to support this project long term.


You can see the dimensions in the full spec table on the preorder page

https://repebble.com/watch


Oh great, I missed that end of the page. The "Round 2 details" links back to the blog and it is hard to see the FAQ on mobile (needs manual scrolling to the end).

Google search and Perplexity failed when I tried, too. Google search has caught up now (haven't retried Perplexity)

A 41.5mm diameter sounds good. That's a whopping 10mm/20% smaller than my current watch. Should be really neat given the thickness.


Yes, the slimness and ability to dress up are certainly huge selling points. It does look about 1/4 thinner than the PT2, which is presumably much thinner/smaller than your fennix.

Honestly, even with a PT2 on order, I would consider getting one of these for the occasions (1x/wk?) where I am wearing a dress shirt or otherwise want to look a little more dressed up. It honestly would probably also be a nice conversation starter because you can set it up with a traditional watchface, but then when you get a notification it would obviously not be a traditional watch. And it's so much thinner than Google/Samsung and other round smartwatches, it wouldn't be confused with those.


I had 8 IPs in a hetzner server years ago. One IP had an iptables rule to accept openvpn on any port.

My openvpn config was a long list of commonly accepted ports on either tcp or udp.

Startup would take a while but the number of times it worked was amazing.


Interesting. But who is OpenDevicePartnership?

Looking at the members on the repository this seems to be a Microsoft project?


Can one even do UEFI firmware projects without at least keeping Microsoft in the loop?

As far as I remmeber, they control the issuance of keys for bootloaders. Or is this project supposed to do away with that?


Already today you can remove the Microsoft keys from most mein board's UEFI and enroll your own. You can perfectly make your own UEFI implementation without Microsoft.


Except that many component manufacturers release their efi capsules signed with Microsoft PKI. So no, you can't fully remove them if you want to verify updates.


While "So no, you can't fully remove them if you want to verify updates" is a valid point, it's also an answer to a different question than the one asked.


You're completely missing the point here.


It's not that Microsoft controls the issuance, it's that their keys are pretty much guaranteed to be installed and thus getting your keys signed with their CA means you can use the pre-existing trust roots.

They are also the one party that is forcing freedom-enabling but formal standard breaking ability of resetting Platform Key, because Microsoft actually documents (or used to) a process to deploy systems signed with your own key as part of the highest security deployment documentation for enterprise customers


If you want to implement UEFI secure boot and verify existing signed objects then you need to incorporate Microsoft-issued certificates into your firmware, but that's very different from needing Microsoft to be in the loop - the certificates are public, you can download them and stick them in anything.


Microsoft even has their own Rust project for UEFI.

https://microsoft.github.io/mu/


Patina is a significant evolution of Mu.

Mu has some bits & pieces of Rust code and EDKII is still the upstream for Mu.

Patina is 100% Rust DXE Core implemented from spec.


Are you somehow related to either projects? You seem to have a good understanding of both pieces :)


Most of the top contributors are @microsoft.com so I would say it's a bit more than just "in the loop".


It's not open. It's not really about devices. And it's certainly not a partnership.


Open as in "open for business".


Compatibility as I understand it means "mixing this in a project is OK".

This is the case if the 2 license aren't at odds. Usually one license is stricter and you have to adhere to that one for the combined work.

A counter-example is GPLv2 and Apache license. Those 2 are incompatible. This was fixed with GPLv3 and you can often upgrade to GPLv3.

So no, this won't allow you to relicense as GPLv2. But you can use GPLv2 code.

This is especially relevant if you have such code redistribution clauses.


  > So no, this won't allow you to relicense as GPLv2. But you can use GPLv2 code.
I don't think your interpretation is correct:

   If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence
To me, this means that the combined work (e.g. EUPL + GPLv2) may be distributed under the "Compatible License" (GPLv2, in this case), but if you were to distribute only the EUPL-licensed work, you would have to distribute it under EUPL.

Besides, I do not think GPLv2 allows you to distribute a combined work under EUPL, for it is listed as GPL-Incompatible. The combined work would have to be distributed under a license compatible with both EUPL and GPLv2.


> Besides, I do not think GPLv2 allows you to distribute a combined work under EUPL, for it is listed as GPL-Incompatible. The combined work would have to be distributed under a license compatible with both EUPL and GPLv2.

AFAICT there is one aspect that seems to trip people when they come from a US-centric view of these licenses (including FSF): IIRC, in EU law a program can be made up of multiple licenses without each one affecting the other parts because the "virality" aspect of GPL (and similar aspects) does not work under the legal framework (because of how what is considered "combined work" under EU). There is an article[0] about why EUPL is not viral (both by choice and because of EU law) that explains it.

The How to use EUPL[1] document also spells it out:

---

But the definition of derivative works depends on the applicable law. If a covered work is modified, it becomes a derivative. But if the normal purpose of the work is to help producing other works (it is a library or a work tool) it would be abusive to consider everything that is produced with the tool as "derivative". Moreover, European law considers that linking two independent works for ensuring their interoperability is authorised regardless of their licence and therefore without changing it: no "viral" effect."

---

Note that in practice since 99.9% of the software in EU also goes outside the EU, including the US, the above doesn't matter much for (A)GPL software so even people (and companies) inside EU treat (A)GPL virality like in US. It is only when it comes to software meant to be used within EU alone (like government software) where the distinction matters.

[0] https://interoperable-europe.ec.europa.eu/collection/eupl/ne...

[1] https://interoperable-europe.ec.europa.eu/collection/eupl/ho...


That is true and an important aspect.

It still does not explain the cognitive dissonance of the EUPL.

1. Source Merging or Statically Linking

Since the EU recognizes that these form derivative works the compatibility provisions in the EUPL are useless. At least as long as they are not interpreted as re-licensing.

2. Dynamically linking or IPC or network requests

If the EU is serious that dynamically linking is not derivative the compatibility provisions in EUPL are not necessary.


I tried a few times as some BIOS have a hidden or disabled setting but I never got past a plain crash. Device and CPU vendor support for classic S3 is shrinking. E.g. on framework laptops the Intel CPU(!) does not officially support S3 sleep.

So I can understand that there is no option for it if all you can get is out of spec behavior and crashes.

Also note that it is incompatible with some secure boot and system integrity settings.


The product page lists EDK II. Is the code available anywhere? I can't see it in edk-platforms.....

I would love to have a UEFI I can compile....


They claim that the documentation and the open-source BIOS/kernel will be released some time in Q1 2025.

It remains to be seen when that happens, but if they keep their promise it will be indeed the first device with any Arm core better than Cortex-A78 that would have adequate documentation and software support.

For all their previous devices Radxa provides their complete schematics and PCB layout, like it was the standard rule many years ago, but now most Western companies have abandoned this good practice. So I expect that this will also be true for Radxa Orion.

For now, NVIDIA Orin is the best Arm-based device that has complete documentation and software support. It has been severely overpriced in the past, but now, when the price has dropped to $250 for an 8-GB Orin Nano developer kit, it has become very competitive.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: