Other comments also hint at this idea, a distributed training solution is currently an open research problem. Solving it is not easy, yet. But 10 years ago what we have today for LLMs would have looked similarly impossible, so have hope, and apply yourself to the problem if you find it interesting!
So the natural extension of this would be plugins which have curated open source allow-lists? Similar to how I trust uBlock Origin's default ad filtering block-lists, I would similarly trust a curated open source allow-list for email domains, and then I would add my own from the "to screen" folder?
Oh, that's a great idea. Currently, every user has their own private list (it's just text files). It takes a bit of work initially, as you need to approve each email, but it's totally worth it. And it must be per user IMO, as your friends and family have different emails, so its less about public or legit domain, but more what domain and e-mail YOU trust.
But great idea, what i added is the opposite direcrection: showing if a sender used spy pixel. There I used public spylists I found.
It was. We had sealed beam headlights for a while till we didn’t. There were common rules for aiming and it worked. The lights weren’t all that bright and the styling was not stellar, however.
I remember having to take my car in to adjust the aiming of the headlights after it didn't pass inspection. So we used to take things like this seriously. I just had my car inspected last month, I don't even remember them hitting the horn. I'm guessing they pretty much just shove a sensor up the exhaust pipe and call it a day while accepting your payment.
No shoving sensors required, the data is all in the ECU accessible over OBDII interface. The car knows if it’s compliant in real time using the sensors it already has.
In states in the USA which perform emissions testing, many of them did not mandate it for diesel cars. For example, I owned a VW Jetta TDI and in New York (which has yearly emissions testing where an OBDII computer is mandated to be connected to gasoline powered cars in order to pass the yearly emissions inspection) and I was exempt from the emissions testing entirely.
A 3rd party sensor would be incredibly expensive for inspection stations to purchase as it would need to meter the air and fuel which enter the engine (assuming we aren't going to trust the car's computer which already knows these figures) as well as to measure the emissions out of the tail pipe. This is economically unrealistic to implement without a dramatic price increase in the cost of regular emissions testing.
Trusting the computer is the economical and realistically widely implementable solution. But yes, it has it's blind spots.
Qualcomm is a “fool me once, shame on you, fool me twice, you don’t fool me twice” kind of situation. So many horrible experiences in the past that people are going to be hesitant.
Qualcomm are trying harder now it seems. But it will take time to repair their reputation in the PC market.
They burned me with the first gen Snapdragon X Elite. Before the various laptops with it were out they promised Linux support. Here we are, years alter, still no fully OOTB support. Ironically, the GPU firmware were just mainlined in the kernel 4 months ago, but they still haven't done the same for the 1st gen X elite.
Tuxedo computers tried and didn't succeed either.
I will never buy Qualcomm again. I avoid them on phones as well by just buying Apple. They do not support their hardware beyond the release.
> I avoid them on phones as well by just buying Apple
To each their own, but I don't recall Apple ever mainlining any of their drivers on Linux. You're rightfully angry on the laptop side of things, but Apple is much worse than Qualcomm when it comes to open source support for their phones.
Qualcomm probably shouldn't have promised Linux support in the first place. Everyone seems to love Apple's hardware even though you're practically stuck with macOS. Had Qualcomm just stuck to Windows-only, they would've probably received a much better reception by the tech press.
Xerox had (maybe still has?) some printers with 5 or 6 color toner capacity. CMYK plus you could order special color toner in stock or fully custom mixes (minimum order sizes apply for full custom) but it was great for companies who had logos which could not be exactly represented by CMYK half toning as the spot color toner could be their exact logo color.
I’m sure the same kind of thing would be possible using Prusa’s documented methods with a little extra work.
I worked on a predecessor to that at Xerox at the start of the 1990s. The first was the Xerox 4850 which was the size of 3-4 clothes washers, cost several hundred thousand dollars, and printed at 50 pages per minute in black plus one color (Xerox called it Highlight Color), but no CMY. It was exactly for the logo use case you mention. A big customer was AT&T for printing phone bills with their blue logo on it. It let them replace many millions of pages of letterhead not sold by Xerox with blank paper sold by Xerox. Xerox loved paper phone bills.
Q8 quant is very minimal fall off in terms of KLD against the lab 16 bit. If you have the memory for BF16 KV-cache (which is usually easier to stomach) then the Q8 is very close. But even Q8 quant model with Q8 KV-cache is very close.
Smaller quants for the model start to fall off but more importantly, smaller KV-cache quants fall off much faster so avoid less than Q8 there.
Would love to see actual security focused hardware/software features, like full OP-TEE, fTPM (or a more ideally a real physical TPM), and similar. For example, so that the OTP isn't the only way to store a disk encryption unlock key.
The existing secure boot mechanisms aren't bad, but allowing for more than one public key hash in OTP would be nice, too.
These kinds of things are expected to be on modern embedded SOCs and SOMs now.
You do know those are trivially bypassed with a signal processor, right? If physical access is outside your threat model, that's OK, but it makes (for example) the forced Win11 upgrade for DRM^H^H^H boot integrity enforcement seem ridiculous.
Yeah, fair enough. "Compliance" is probably the phrasing I should've used, rather than "security".
I've been curious for a while about the overall taxonomy of security, especially for embedded platforms. It seems like the only hope is defense in depth, given the power glitching attacks and the like that you can find demonstrated.
Specific to the Raspberry Pi, I believe I even saw a thread at some point where one of their firmware engineers was making the case that secure boot on the Pi 5 was equivalent to a TPM in almost any reasonable threat model, since, in either case, you were out of luck if an attacker had physical access and was willing to put in enough effort.
Normal secure boot does not use the TPM. Secure boot is the proactive process of ensuring only allowed code loads and executes.
The TPM is used for measured boot, the post process to understand what actually was booted and if the right set of things were booted then to allow unlocking of specific items like keys.
Both are important but they are not the same thing.
It's a pretty normal thing to do for small LCD screens. Linux has had SPI framebuffer support via fbtft subsystem (in staging tree now, previously was out of tree) for well over a decade. It works quite well.
Many silicon vendors, when providing said binary blobs to a device OEM or even just documentation or source code for the binary blobs, will make companies agree to a license or other legal terms which prohibits reverse engineering. Often the direct recipient of the binary blobs (the OEM of the device) cannot legally let their employees nor contractors perform the reverse engineering.
Generally, unless a similar license or legal terms are required to be agreed to by the end user, nothing stops the end user from reversing said binary blobs. But before you attempt this, be sure you fully understand every legal document which was presented to you by the device vendor. Click-through EULAs included.
There’s lies, damn lies, and lies that disks tell the operating system. Don’t believe any of them!
If you need to know it’s been persisted to non-volatile storage then you need to own the full stack of every piece of software between the OS and the actual physical memory.
Every managed flash drive is going to have layers and layers of complexity and caching and things you simply can’t easily control or really understand. Don’t trust it unless you know exactly how it works all the way down.
Well said and there are some bitter lessons in the storage industry.
In my last company we need to disable the disk write cache during each reboot, and we also heard a lot industry stories related to underneath firmware implementation from oxide computer podcasts [1]. Yes, to provide truly reliable service, we need to evaluate underneath hardware settings case-by-case.
reply