HN user

ByteWelder

432 karma
Posts5
Comments67
View on HN

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.

That app is just an internal one for when people build their own firmware. The external apps have recently moved to https://github.com/ByteWelder/TactilityApps

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.

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.

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.

(from https://en.wikipedia.org/wiki/Skeuomorph)

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.

Sources (in Dutch): - https://www.ondernemenmetpersoneel.nl/orienteren/dienstverba... - https://noestadvocatuur.nl/zzper-werknemer/

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.

* they do want to help keep your children safe

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.

I must say, I wish for the old days back. Sure, it was slow and laborious, but it resulted in better outcomes and manageability. IMHO, it also resulted in better reliability of software due to the diligence done by several layers.

Those were also the days where it took many years to go from Java 6 to Java 8. Or perhaps to try out Kotlin.

They were the days where legacy code was the norm, and we kept supporting it because nobody dared to change anything for the better. In practice, that's just not something you can maintain in a competitive market, because your competitors _will_ use new technologies and faster/better development processes.

"it just works" might be good enough for maintaining your application, but will it be good enough to find people willing to work in that code base or that environment?

I work for a large business where both the old and new practices are in place (mostly the new ones, though). Focusing on "going fast" is definitely not a good idea, but I believe there's a sweet spot in between.

they are and were supported by a smaller group of people who do really good work

I think the only solution for this is when "support" includes education. In the simplest form, we can give support by helping that colleague to find the issue himself, rather than giving the solution directly. In a more advanced form, you're making structural changes to your company. Like in how you share knowledge with the team.

I concur. At this point, it's probably better to create some kind of virtual machine as a compatibility layer. That way it can be updated separately and it doesn't need to be part of the actual system. Alternatively, it could probably be a sub-system like WSL - and completely optional.