I'm not them but whenever I've used it it's been for arch specific features like adding a debug breakpoint, synchronization, using system registers, etc.
Never for performance. If I wanted to hand optimise code I'd be more likely to use SIMD intrinsics, play with C until the compiler does the right thing, or write the entire function in a separate asm file for better highlighting and easier handing of state at ABI boundary rather than mid-function like the carry flags mentioned above.
Generally inline assembly is much easier these days as a) the compiler can see into it and make optimizations b) you don’t have to worry about calling conventions
> the compiler can see into it and make optimizations
Those writing assembler typically/often think/know they can do better than the compiler. That means that isn’t necessarily a good thing.
(Similarly, veltas comment above about “play with C until the compiler does the right thing” is brittle. You don’t even need to change compiler flags to make it suddenly not do the right thing anymore (on the other hand, when compiling for a different version of the CPU architecture, the compiler can fix things, too)
It's rare that I see compiler-generated assembly without obvious drawbacks in it. You don't have to be an expert to spot them. But frequently the compiler also finds improvements I wouldn't have thought of. We're in the centaur-chess moment of compilers.
Generally playing with the C until the compiler does the right thing is slightly brittle in terms of performance but not in terms of functionality. Different compiler flags or a different architecture may give you worse performance, but the code will still work.
“Advanced chess is a form of chess in which each human player uses a computer chess engine to explore the possible results of candidate moves. With this computer assistance, the human player controls and decides the game.
Also called cyborg chess or centaur chess, advanced chess was introduced for the first time by grandmaster Garry Kasparov, with the aim of bringing together human and computer skills to achieve the following results:
- increasing the level of play to heights never before seen in chess;
- producing blunder-free games with the qualities and the beauty of both perfect tactical play and highly meaningful strategic plans;
- offering the public an overview of the mental processes of strong human chess players and powerful chess computers, and the combination of their forces.”
Well I have benchmarks where my hand-written asm (on a fundamental inner function) beat the compiler-generated code by 3× :) Without SIMD (not applicable to what I was trying to solve).
And that was already after copious `assert_unchecked`s to have the compiler assume as many invariants as it could!
> “play with C until the compiler does the right thing” is brittle
It's brittle depending on your methods. If you understand a little about optimizers and give the compiler the hints it needs to do the right things, then that should work with any modern compiler, and is more portable (and easier) than hand-optimizing in assembly straight away.
Well in my case I had to file an issue with the compiler (llvm) to fix the bad codegen. Credit to them, it was lightning fast and they merged a fix within days.
Of course you can often beat the compiler, humans still vectorize code better. And that interpreter/emulator switch-statement issue I mentioned in the other comment. There are probably a lot of other small niches.
In general case you're right. Modern compilers are beasts.
Might be an interpreter or an emulator. That’s where you often want to preserve registers or flags and have jump tables.
This is one of the remaining cases where the current compilers optimize rather poorly: when you have a tight loop around a huge switch-statement, with each case-statement performing a very small operation on common data.
In that case, a human writing assembler can often beat a compiler with a huge margin.
I'm curious if that's still the case generally after things like musttail attributes to help the compiler emit good assembly for well structured interpreter loops:
LLVM codegen has been almost always sufficient, but for a routine that essentially amounts to adding two fixed-size bigints (e.g. 1024-bit ints represented as `[u64; 16]`), codegen was very very bad.
Writing a jump table by hand literally made the code 3× faster :)
Private repositories are only allowed for things required for FLOSS projects, like storing secrets, team-internal discussions or hiding projects from the public until they're ready for usage and/or contribution.
They are also allowed for really small & personal stuff like your journal, config files, ideas or notes, but explicitly not as a personal cloud or media storage.
So the ToS says only private repos that support FLOSS, but then backdoors into "small & personal stuff" which is pretty loose and up to Codeberg's discretion so probably not the best place for your private side project repos.
You're right, and after thinking about it a bit more, I think this TOS is actually more confusing than what came before. Saying explicitly that, e.g. MIT licensed software was allowed (because that license is approved by OSI), makes it unambiguous. This feels like if someone complained or had too many repos they're liable to get nuked from orbit. That being said Forgejo is FLOSS and this service is hosted for free so they're allowed to set whatever terms they want. I'll delete my upthread comment as it's misinfo.
No problem. I'm confused by it as well. I migrated a repo that is more source available than open source and didn't realize that it probably is against ToS until afterwards.
> Interviewed, she warns that she will “not stop pursuing publishers if links are discovered with a criminal organization and they [GrapheneOS] do not cooperate with justice.”
France has threatened us with the same actions they took against SkyECC and Encrochat if we do not cooperate by providing law enforcement access into devices. The actions they took against those were mass arrests and seizure of servers. We don't have cloud infrastructure for builds/signing but regardless we don't want the French state taking over our website, etc. so we're leaving France and OVH.
It's not clear what they mean by that in the threats they've made in multiple places but it's clearly a threat, and they're already lying about us. Therefore, we're leaving France including leaving OVH and not hiring people in France without them relocating first. Our most sensitive infrastructure is local but we don't want a state taking over our website and network services. We don't trust France and OVH to respect rule of law and human rights at this point. It's not a safe country for open source privacy projects and French companies cannot be trusted to even host a static website without hijacking it for French law enforcement.
French law enforcement is conflating companies making products with GrapheneOS code with GrapheneOS itself. They're presenting it as if those companies are working with us and that we're responsible for their actions selling devices using our code. Most of those are using forks of GrapheneOS with features we don't have which are repeatedly incorrectly referred to as being GrapheneOS features. GrapheneOS users can read the many articles and see many references to non-existent features. They similarly refer to non-existent distribution methods and marketing which are actually about these products they're conflating with us. Since they're conflating products and actions by other people with ours, that makes their threats very concerning.
GrapheneOS doesn't even currently bundle an end-to-end encrypted messaging app as we don't have our own and leave choosing third party apps up to users. We plan to make an RCS app with MLS to replace people using Google Messages via sandboxed Google Play but that's no different than what Apple and Google are working towards providing earlier. Even if Chat Control was already the law, we don't have Signal or a similar app bundled with the OS and don't currently distribute a hardened build via our App Store despite plans for it. We do distribute the sandboxed Play Store and Accrescent via our App Store which have end-to-end encrypted messaging apps available...
> We don't trust France and OVH to respect rule of law and human rights at this point. It's not a safe country for open source privacy projects and French companies cannot be trusted to even host a static website without hijacking it for French law enforcement.
Probably the former. SkyECC, Encrochat, etc, were found to be deliberately sold to nontechnical drug lords for large amounts of money - as in, the project leads went out searching for drug lords and selling phones to them individually and offered to sell them 100 phones for $200 per month per phone. Drug empires have that sort of money. And they didn't sell to anyone else since nobody else has that sort of money.
It seems unlikely that GrapheneOS is the same way, since it's free, but you never know - maybe it is made for drug lords, and giving it away to the rest of us is just for plausible deniability.
This is not proven state action - this is hearsay. Maybe the GrapheneOS project should wait for the first warrant to arrive or police raid to happen before claiming what they currently do.
With the current evidence, its not ruled out that the french state is not doing anything at all.
The commentor means Dual_EC, a random number generator. The backdoor was patented under the form of "escrow" here: https://patents.google.com/patent/US8396213B2/en?oq=USOO83.9... - replace "escrow" with "backdoor" everywhere in the text and what was done will fall out.
ML-KEM/ML-DSA were adapted into standards by NIST, but I don't think a single American was involved in the actual initial design.
There might be some weakness the NSA knows about that the rest of us don't, but the fact they're going ahead and recommending these be used for US government systems suggests they're fine with it. Unless they want to risk this vulnerability also being discovered by China/Russia and used to read large portions of USG internet traffic. In their position I would not be confident that if I was aware of a vulnerability it would remain secret, although I am not a US Citizen or even resident, and never have been.
Not that I think this is the case for this algorithm, but backdoors like the one in Dual_EC cannot be used by a third party without what is effectively reversing an asymmetric key pair. Their public parameters are the product of private parameters that the NSA potentially has, but if China or whoever can calculate the private parameters from the public ones it’s broken regardless.
Indeed. Dual_EC was a NOBUS backdoor relying on the ECDLP. That's fair.
My point was more that it looked suspicious at the time (why use a trapdoor in a CSPRNG) and at least the possibility of "escrow" was known, as evidenced by the fact that Vanstone (one of the inventors of elliptic curve cryptography) patented said backdoor around 2006.
This suspiciousness simply doesn't apply to ML-KEM, if one ignores one very specific cryptographer.
There is no reason to hard fork, as long as Google contributes to AOSP without breaking it.
Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.
I actually wonder: if Google stopped pushing to AOSP and "the community" had to fork... the whole Android SDK/NDK is not open source, so I wonder if AOSP could survive at all without Google, even though it is open source.
I think if Google would stop pushing AOSP, there's a very high risk for Google that a consortium of manufacturers would continue themselves as they need it and they would lose control.
I think that is unlikely reality because from manufacturers perspective they don't get AOSP from the public. They get it from their chip provider like Qualcomm who gets private releases from Google. Everything is already set up such that people aren't using the public version, so the more likely reality is that the public version goes away, and google partners keep doing what they are doing. Maybe things are different on the Chinese side of things. So if it were to be created, it would be over there.
Would they, though? Like Huawei forked for a while, and then they made their proprietary HarmonyOS.
For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.
Android does that already and allows apps to use it (the webview)
reply