I understand the concerns and anger of GrapheneOS's leadership, but the hyper-escalation tactic doesn't do what they hope: First, it sends a message of inexperience in business, negotiation, and conflict resolution: 'I'm going to take my ball and leave' - it looks like an emotional overreaction without strategic thinking. These days you sometimes see powerful parties making similar threats - e.g., Uber threatening to leave certain markets. But those people have significant power and their tactic is really to demonstrate that in order to shift their negotiating position; usually they don't actually decamp, and GrapheneOS has relatively little power so that tactic doesn't apply. As importantly, it sends the message that GrapheneOS can be pushed around and manipulated: A slight hint of a threat and they flee. Others will take note, and many will think the same of other FOSS projects, large and small - they are easily intimidated and dismissed. Another reason people don't use these tactics is that they have other important interests besides the one under immediate threat. A requirement of anyone with significant investments that can't be easily abandoned - which is everyone doing anything of value - is to navigate in a way that upholds all those interests. You don't burn down the house to kill a rat. It can be hard and requires careful, deliberate thought and strategy. One unmentioned interest that might appeal to GrapheneOS's leadership is the freedoms of people in France to create FOSS, and to individual privacy and security.
Having had some experience teaching and designing labs and evaluating students in my opinion there is basically no problem that can't be solved with more instructor work. The problem is that the structure pushes for teaching productivity which basically directly opposes good pedagogy at this point in the optimization. Some specifics: 1. Multiple choice sucks. It's obvious that written response better evaluates students and oral is even better. But multiple choice is graded instantly by a computer. Written response needs TAs. Oral is such a time sink and needs so many TAs and lots of space if you want to run them in parallel. 1.5 Similarly having students do things on computers is nice because you don't have to print things and even errors in the question can be fixed live and you can ask students to refresh the page. But if the chatbots let them cheat too easily on computers doing hand written assesments sucks cause you have to go arrange for printing and scanning. 2. Designing labs is a clear LLM tradeoff. Autograded labs with testbenches and fill in the middle style completetions or API completetions are incredibly easy to grade. You just pull the commit before some specific deadline and run some scripts. You can do 200 students in the background when doing other work its so easy. But the problem is that LLMS are so good at fill in the middle and making testbenches pass. I've actually tried some more open ended labs before and its actually very impressive how creative students are. They are obviously not LLMs there is this diversity in thought and simplicity of code that you do not get with ChatGPT. But it is ridiculously time consuming to pull people's code and try to run open ended testbenches that they have created. 3. Having students do class presentations is great for evaluating them. But you can only do like 6 or 7 presentations in a 1 hr block. You will need to spend like a week even in a relatively small class. 4. What I will say LLMs are fun for are having students do open ended projects faster with faster iterations. You can scope creep them if you expect expect to use AI coding.
France has made it clear they expect to have a backdoor in end-to-end encryption apps and disk encryption. They've been saying that it's unacceptable not to have a backdoor in a bunch of these news stories they've gotten published by contacting the media. They've said if we don't cooperate with that, they'll take similar actions against us as they did SkyECC and Encrochat meaning hijacking our servers and trying to have us arrested. Le Parisien has 2 articles about this, not only one, and https://archive.is/UrlvK is one of the places they talk about going after us if we don't cooperate with providing them access to devices. It's not possible for us to provide an update which bypasses the throttling for brute force protection so what they're asking isn't even helping them break into specific devices but helping them compromise security for everyone in anticipation of rare cases of criminals using devices. https://news.ycombinator.com/item?id=46038241 explains lack of technical ability to compromise security after the fact. Titan M2 is specifically designed with insider attack resistance so that Google making an update disabling the brute force protection won't be accepted by the secure element without the Owner user successfully unlocking first. We don't have the signing key for the Titan M2 firmware anyway. This is part of our required hardware-based security features which we're working on providing in a Pixel alternative with a major Android OEM working with us right now. We talked to them about the France situation already and it does not negatively impact our partnership. It may be a good idea to speed up an official announcement with them to counter the narrative being pushed by France's law enforcement agencies now.
> Prior to that issue Rust was using something much worse, pthread_mutex_t Presumably you're referring to this description, from the Github Issue: > > On most platforms, these structures are currently wrappers around their pthread equivalent, such as pthread_mutex_t. These types are not movable, however, forcing us to wrap them in a Box, resulting in an allocation and indirection for our lock types. This also gets in the way of a const constructor for these types, which makes static locks more complicated than necessary. pthread mutexes are const-constructible in a literal sense, just not in the sense Rust requires. In C you can initialize a pthread_mutex_t with the PTHREAD_MUTEX_INITIALIZER initializer list instead of pthread_mutex_init, and at least with glibc there's no subsequent allocation when using the lock. But Rust can't do in-place construction[1] (i.e. placement new in C++ parlance), which is why Rust needs to be able to "move" the mutex. Moving a mutex is otherwise non-sensical once the mutex is visible--it's the address of the mutex that the locking is built around. The only thing you gain by not using pthread_mutex_t is a possible smaller lock--pthread_mutex_t has to contain additional members to support robust, recursive, and error checking mutexes, though altogether that's only 2 or 3 additional words because some are union'd. I guess you also gain the ability to implement locking, including condition variables, barriers, etc, however you want, though now you can't share those through FFI. [1] At least not without unsafe and some extra work, which presumably is a non-starter for a library type where you want to keep it all transparent.
 Top