I've been working for two years on an open source application platform for ESP32. It's a light-weight operating system that can download and run native applications. I wrote an article about the developments in the past year.
It's still not much, but more will be made in the coming months. I wanted to stabilize the APIs a bit more before making more apps.
I almost finished a Diceware app.
I have been considering that hardware, but the UI isn’t currently fit for such small screens. I’m considering T-Embed first, so when that works, it might be easier to adapt for Cardputer too.
Ease of development: programming WiFi, for example, takes easily 200 lines of code with ESP-IDF SDK. And your credentials will be baked into the ROM as plain text. With Tactility it’s stored safely and all you have to do is toggle the WiFi toggle on.
You can also run multiple apps alongside, making your ESP32 device more of a multitool like Flipper Zero.
Interesting - never heard of it. I found another project(*) that runs Mobian on a Pi, so that should work. I intend to try out ParrotOS and/or Kali in the future. Perhaps some RTL-SDR tinkering too.
It's built with a Raspberry Pi CM4 and a 5" touch screen. It has about 6 hours of battery life and batteries are replaceable. The keyboard isn't great, but it's functional.
Inspiration and motivation came from Yarh.io, uConsole and various handheld PCs from the past.
For those (like me) being stuck on "skeuomorphic" in the second sentence:
> A skeuomorph is a derivative object that retains ornamental design cues (attributes) from structures that were necessary in the original. Skeuomorphs are typically used to make something new feel familiar in an effort to speed understanding and acclimation. They employ elements that, while essential to the original object, serve no pragmatic purpose in the new system. Examples include pottery embellished with imitation rivets reminiscent of similar pots made of metal and a software calendar that imitates the appearance of binding on a paper desk calendar.
> It not reasonable to hold Apple to pledges they've made to western customers, when talking about a service provided to non-western customers.
I think it's reasonable: We hold people account across borders for serious violations (extraditions), so it's completely reasonable to hold a company accountable for its serious violations outside of the country that you're buying from.
No-one is forcing Apple to support those countries with oppressing citizens either.
The regulations in The Netherlands in this regard have recently (May 20160) been updated to prevent fake freelance/independent status.
There are a bunch of guidelines, but the main factors generally boil down to these questions: Is the employee working for a single employer? How much independence do they have? (e.g. holidays, working hours, etc.)
Were the contract details mandated by the employer? etc.
If a developer is hit by this while having to deal with hundreds or even thousands of warnings: how would they know when a new warning is introduced in that massive pool of warnings? That seems very dangerous in the context of kernel development.
Some warnings can hint about serious issues (e.g. dangerous casting). This can lead to bugs with very serious consequences.
I want native apps because I want a native experience: Keyboard shortcuts and UX patterns should be consistent throughout most applications. I'm fine with some exceptions (e.g. video editing, photo editing, etc.), but generally I want consistency.
I want native apps because my bought RAM and CPU cycles are precious resources: they shouldn't be treated like a "free for all" by lazy devs. Not every native dev uses these sparingly, but in my professional experience, web devs often don't even consider it being a factor during development.
I want web apps to run in my web browser, so I can apply privacy-enabling plugins to them like uBlock. I also don't want web apps implementing dark patterns to get me into their hybrid app. (e.g. MS Teams forcing me to reconsider every time I open the website)
Yes: E2EE and not having the ability to scan is a legit alternative.
Apple has lost its credibility as a privacy-enabler. That's a real consequence, as opposed to a potential consequence of being targeted by propaganda.
The main issue with privacy is not necessarily the initial implementation, but the sliding scale that it permits. Apple's statement that they will ignore "government requests" for broadening the scope is almost funny, because the government wouldn't request: it would demand. Just like how China has control over the crypto keys for the iCloud data in Chinese data centers.
So you're right that the initial plan is indeed more privacy-friendly, but it has some major future privacy implications that are much worse.
Well-meaning intentions are irrelevant to what's effectively happening on the bottom line.
> * they told you in detail how the system would work
This is great though. In any normal situation, this would build trust. Not so much in this case, because of the impact on privacy and potential for abuse.
> * they are holding off on releasing after the world gave them feedback
The crucial part is that they still intend to continue with their plan. They'll possibly modify it, but we'll have to see what that means. Well-intentioned backdoors are still backdoors.
> Who else is doing better?
That's completely irrelevant to the discussion.
Just to humour the question: Android (AOSP), Pine (from PinePhone), Librem, CalyxOS and GrapheneOS are some products and operating systems that I could think off that respect the users' privacy better.
> I get that you don’t like the system, but how do you solve it? Is it not worth solving? Too easy to nix ideas without contributing to the conversation.
Customers don't have any responsibility to solve this. It's totally in the customers' right to complain and say "we don't want this feature". For good reasons, as shown by all the experts and privacy advocacy groups.