raggi

A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.

Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).

Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.

Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.

Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations

When the topic comes up some people express a lot of hatred for uefi (mostly users rather than implementors) but where it’s implementors the ms style APIs and so on are largely the center of it IME, and that’s not really an easy fix when it’s already spec’d. Sometimes there are concerns about size, but slimmed down deployments are common in the socs that ship already - perhaps standardizing on what that slimmed down thing is might help too. May also assuage some of the other concerns of excessive runtime services (which seems rare, but I get the existential concern)

It wasn’t anywhere near that late the numbers you’re saying was about the whole build cycle - board bringup for one of the two boards first commit in zircon was 3y before launch (that codes public, I just checked and Mike landed it in 2018) - and discussions weren’t done then, that was before any prototype/demos could be done. There were sluggish stages and project management was rough, and there were delays at the end related to quality but the quality bar was necessarily high, particularly on the core system - don’t brick all the devices in the field. And we didn’t, and that’s actually a feat replacing everything from firmware to gui in the field without users noticing.

What was the goal? Well two things: fuchsia needed a first, and realistic shipping target that wasn’t excessively lofty. Nest needed to get out of the OS game so it could focus resources on product. Chris talked about this in his 9to5google interview.

It’s a shame you feel so sour about it, everyone involved did good work. I have friends from nest and some of the ics also have similar pained history from that time - it’s sad, once upon a time it was maddening. It’d have been so easy for a leader to substantially improve that. Sure plenty of things could have been better, for sure we could have fixed these awful sentiment and relationship issues (I tried, got burned for it - that even showed up in my calibration), but we all shipped.

Excerpt from the user agreement:

    When Your Content is created with or submitted to the Services, you grant us a worldwide, royalty-free, perpetual, irrevocable, non-exclusive, transferable, and sublicensable license to use, copy, modify, adapt, prepare derivative works of, distribute, store, perform, and display Your Content and any name, username, voice, or likeness provided in connection with Your Content in all media formats and channels now known or later developed anywhere in the world. This license includes the right for us to make Your Content available for syndication, broadcast, distribution, or publication by other companies, organizations, or individuals who partner with Reddit. For example, this license includes the right to use Your Content to train AI and machine learning models, as further described in our Public Content Policy. You also agree that we may remove metadata associated with Your Content, and you irrevocably waive any claims and assertions of moral rights or attribution with respect to Your Content.

"novel" here depends on what you mean. Could an LLM produce output that is unique that both it and no one else has seen before, possibly yes. Could that output have perceived or emotional value to people, sure. Related challenge: Is a random encryption key generated by a csprng novel?

In the case of the US copyright office, if there wasn't sufficient human involvement in the production then the output is not copyrightable and how "novel" it is does not matter - but that doesn't necessarily impact a prior production by a human that is (whether a copy or not). Novel also only matters in a subset of the many fractured areas of copyright laws affecting the space of this form of digital replication. The copyright office wrote: https://www.copyright.gov/ai/Copyright-and-Artificial-Intell....

Where I imagine this approximately ends up is some set of tests that are oriented around how relevant to the whole the "copy" is, that is, it may not matter whether the method of production involved "copying", but may more matter if the whole works in which it is included are at large a copy, or, if the area contested as a copy, if it could be replaced with something novel, and it is a small enough piece of the whole, then it may not be able to meet some bar of material value to the whole to be relevant - that there is no harmful infringement, or similarly could cross into some notion of fair use.

I don't see much sanity in a world where small snippets become an issue. I think if models were regularly producing thousands of tokens of exactly duplicate content that's probably an issue.

I've not seen evidence of the latter outside of research that very deliberately performs active search for high probability cases (such as building suffix tree indices over training sets then searching for outputs based on guidance from the index). That's very different from arbitrary work prompts doing the same, and the models have various defensive trainings and wrappings attempting to further minimize reproductive behavior. On the one hand you have research metrics like 3.6 bits per parameter of recoverable input, on the other hand that represents a very small slice of the training set, and many such reproductions requiring strongly crafted and long prompts - meaning that for arbitrary real world interaction the chance of large scale overlap is small.

https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...

This is similar to the ruling by Alsup in the Anthropic books case that the training is “exceedingly transformative”. I would expect a reinterpretation or disagreement on this front from another case to be both problematic and likely eventually overturned.

I don’t actually think provenance is a problem on the axis you suggest if Alsups ruling holds. That said I don’t think that’s the only copyright issue afoot - the copyright office writing on copyrightability of outputs from the machine essentially requires that the output fails the Feist tests for human copyrightability.

More interesting to me is how this might realign the notion of copyrightability of human works further as time goes on, moving from every trivial derivative bit of trash potentially being copyrightable to some stronger notion of, to follow the feist test, independence and creativity. Further it raises a fairly immediate question in an open source setting if many individual small patch contributions themselves actually even pass those tests - they may well not, although the general guidance is to set the bar low - but is a typo fix either? There is so far to go on this rabbit hole.

You're right stability comes from testing, not enough testing happens around Linux period, regardless of which branch is being discussed.

It's not easy testing kernels, but the bar is pretty low.

Both of the systems are crap, when we were evaluating them for nationwide purchase we chose TETRA because of systemic safety features (like local DMO handover modes for public safety use in noisy environments), but when I read their crypto choices I made screwy faces constantly, I wasn't in the slightest bit surprised when this research came out.

I remember at the time some ex signals military folks trying to tell me that the encryption barely matters as the channel selection rate is so high you'd need multi-site intercepts to even make heads of tails of it, sadly they didn't really seem to understand how far SDR and compute has come. The whole experience to this day flavors a lot how I think about military and telco thinking around the whole space, everything touching that boundary feels infected with oldthink.

        use std::io;
        
        #[cfg(unix)]
        fn raise_file_limit() -> io::Result<()> {
            use libc::{getrlimit, setrlimit, rlimit, RLIMIT_NOFILE};
            
            unsafe {
                let mut rlim = rlimit {
                    rlim_cur: 0,
                    rlim_max: 0,
                };
                
                if getrlimit(RLIMIT_NOFILE, &mut rlim) != 0 {
                    return Err(io::Error::last_os_error());
                }
                
                rlim.rlim_cur = rlim.rlim_max;
                
                if setrlimit(RLIMIT_NOFILE, &rlim) != 0 {
                    return Err(io::Error::last_os_error());
                }
            }
            
            Ok(())
        }