3,510 karma · joined April 1, 2010
[ my public key: https://keybase.io/ge0rg; my proof: https://keybase.io/ge0rg/sigs/IbGDkSaF88bGZ5TR2pBfzVgSpIjQIR2ujem0AQx0qms ]
All the other hacks for NX1, including NX-KS2, are listed at https://github.com/ottokiksmaler/nx500_nx1_modding
My most fascinating find was actually the Galaxy NX, which is an Android 4 phone with a dedicated camera SoC running the same flavor of Tizen Linux as the NX300.
Edited to add: Since Dpreview is shutting down, I've also created a reddit for the Samsung NX fans: https://old.reddit.com/r/SamsungNX/
The NX mini is a great little device, but it was badly marketed and priced, and its manual focus is utterly unusable. I so much wish that the mini2 would've been released before exiting the market!
Create an account group to help us understand if there are any other developer accounts that you're associated with. We'll use this information to make sure that you're eligible for Google Play developer programs and services, such as the 15% service fee.
This looks like a fully arbitrary requirement that has nothing to do with the 15% fee and everything with Google collecting as much data as it can get away with.
Starting July 1, 2021, the service fee for each developer will be 15% for the first $1M (USD) of earnings you make each year when you sell digital goods or services.
However, when you read on, you realize that it's an opt-in that you need to take action on:
To officially enroll for the 15% service fee tier, you must: [list of requirements and steps]
We are reviewing the most important specifications on a yearly base and provide recommendations in the form of Compliance Suites with different profiles like Instant Messaging, Mobile etc.:
My Amazon income is less than 2% of the Google income.
The wrong parity and unrecoverable errors has been confirmed by multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally flawed
It would be interesting to know if this has been addressed already.
The big fat red warning on btrfs' own wiki page is not inspiring trust either: https://btrfs.wiki.kernel.org/index.php/RAID56
For data, it should be safe as long as a scrub is run immediately after any unclean shutdown
An open push framework only makes sense (for battery optimization at least) if it's centralized, and all applications make use of it.
This is so f*ing scary. Who in their right mind invents such crazy tricks that absolutely circumvent all we know about web API security, implements them in frameworks, and leaves them enabled by default?
* https://news.ycombinator.com/item?id=12971503
* https://news.ycombinator.com/item?id=12966673
* https://news.ycombinator.com/item?id=12974121
Potential counter measure: https://news.ycombinator.com/item?id=13118227
Otherwise, the page probably wouldn't run off github.
But for later connections, it is essentially defining a caching of:
- a boolean flag that a trusted certificate is to be used
- a flag whether violations are to be reported to an endpoint obtained from untrusted DNS
- a maximum age of this "policy"
how is it superior to:
- just querying / dumping this policy as informational headers after STARTTLS (possibly guarded by a new EHLO feature)
- TLS TACK (https://tools.ietf.org/html/draft-perrin-tls-tack-00), which is kind of abandoned, but is an equivalent to HSTS, just at the correct layer
and how does it solve the problem that even if you have a policy defined, a MitM attacker can just redirect all policy reports with a very-long-lived _smtp._tls.example.com DNS record pointing to their own property or to nowhere?