and it seems Google wants to support people like you!
That entire QR barcode thing is so that you can browse the web on your laptop/desktop, and _still_ rely on smart phone's attestation, no mobile browser needed.
This seems to be some sort of PHP upload/download tool, together with its own custom protocol and custom client.
But why? If you have server access, use it directly. There are plenty of programs which can sync over SCP/SFTP/FTP etc.. directly, no need for some weird PHP shell and custom protocol and 2nd password...
23 atomic bombs per day does not really tell me much. Both boxer's punch and a 9mm bullet have about 450 J of energy, but the effects are very different.
A better comparison would be ~550000 average US houses... or a single medium-sized aluminum smelter factory.
Thats why they gave the measurement in watts (which is power) and not joules (which is energy). The answer is that even if the fist and the bullet transfer equivalent amounts of energy the bullet has significantly higher instantaneous power because the energy is transferred over a shorter period of time.
> A better comparison would be ~550000 average US houses... or a single medium-sized aluminum smelter factory.
Want to provide a citation for either of these? This would have the average US household dissipating the equivalent of ~30kW, which does not pass the smell test for me.
Do you install system-wide software at all? How do you configure it?
That's my main reason to use "sudo" on the desktop.
I suppose I could install every piece of software locally, either from source or via flatpak, but this is a lot of work and much harder than doing it the easy way and using global install via my distro. Plus, non-distro installs are much more likely to be out of date and contain vulnerabilities of their own.
Note that capabilities would not help for those bugs we are discussing today.
Those exploits are in kernel, and the userspace is only calling the normal, allowed calls. Removing global open()/listen()/etc.. with capability-based versions would still allow one to invoke the same kernel bugs.
(Now, using microkernel like seL4 where the kernel drivers are isolated _would_ help, but (1) that's independent from what userspace does, you can have POSIX layer with seL4 and (2) that would be may more context switches, so a performance drop)
> Note that capabilities would not help for those bugs we are discussing today.
Yes they would. Copyfail uses a bug in the linux kernel to write to arbitrary page table entries. A kernel like SeL4 puts the filesystem in a separate process. The kernel doesn't have a filesystem page table entry that it can corrupt.
Even if the bug somehow got in, the exploit chain uses the page table bug to overwrite the code in su. This can be used to get root because su has suid set. In a capability based OS, there is no "su" process to exploit like this.
A lot of these bugs seem to come from linux's monolithic nature meaning (complex code A) + (complex code B) leads to a bug. Microkernels make these sort of problems much harder to exploit because each component is small and easier to audit. And there's much bigger walls up between sections. Kernel ALG support wouldn't have raw access to overwrite page table entries in the first place.
> (2) that would be may more context switches, so a performance drop
I've heard this before. Is it actually true though? The SeL4 devs claim the context switching performance in sel4 is way better than it is in linux. There are only 11 syscalls - so optimising them is easier. Invoking a capability (like a file handle) in sel4 doesn't involve any complex scheduler lookups. Your process just hands your scheduler timeslice to the process on the other end of the invoked capability (like the filesystem driver).
But SeL4 will probably have more TLB flushes. I'm not really sure how expensive they are on modern silicon.
I'd love to see some real benchmarks doing heavy IO or something in linux and sel4. I'm not really sure how it would shake out.
So they use LLM to evaluate LLMs: with LLM writing the questions, another LLM writing the country-specific answers, and yet another LLM getting the country from an answer. The only manual steps seem to be "manually reviewed [questions] to remove repetitions or accidental location references."
This seems like a pretty lazy methodology, as if there are LLM-specific country biases, they could be introduced at any stage of the process.
Note this uses DJGPP, which switches processor to 32 bit mode via DPMI. You won't get old-school experience of segmented memory, near pointers and 64KB limits everywhere.
Service accounts are great! I just wish instead of having a password which gets shared around via 1password, there were a clear permission list ("this is a service account.. "real" users X, Y, X can login as it")
Seems like it's just Microsoft that cannot figure it out. AWS had roles forever, fully supported from web console or CLI. But when I request Azure service account, I am handed username and password.
The question is how to tell which code is unsafe. In some languages it is easier, in some languages it's much harder.
For example in C and in C++, every line is potentially unsafe, so you have to verify the entire program very, very carefully.
On the other hand Java is safe, unless you mess with JNI. This is a very infrequently used feature, so for most programs you can be 100% sure there are no certain class of safety issues.
Rust has specific "unsafe" keyword - if you see it in a program, you have to be very careful. You can write quite a lot of Rust without ever using it.
That entire QR barcode thing is so that you can browse the web on your laptop/desktop, and _still_ rely on smart phone's attestation, no mobile browser needed.
reply