The kindle hardware is excellent, but the kindle software is one of the worst pieces of garbage ever. Just filled from top to bottom with utterly deranged behaviors.

The thing that drives me crazy is that when you select word to translate, it includes commas and points. Then, dictionary can't translate!!! This is such a basic issue and still exists for years. Ppl from Amazon, I pray to you to fix this

I've complained about these issues with the Kindle for years, but the problem is that Amazon has absolutely no incentive to fix any of these issues.

Agreed. But in its defense, the software on my Kindle has remained the same level of bad for the last 8 years. Compared to my Android devices that have slowed down significantly.

I echo your sentiments about a Leatherman.

I carried a cheaper Wingman religiously for five years. I bought it on a whim during a sale at a hardware store thinking I would keep it in the car for emergencies. It quickly became a pocket staple. Over the five years that thing fixed my car on the side of the road, was used at my job every 30 minutes, hammered loose nails, fell off a roof, cut my dinner. You name it.

Another thing to mention is how well the tools that comprise the leatherman itself are integrated into the package. Depending on the loadout/model you choose, you can have an array of quick-access functionality without any fumbling. The hinge mechanism for the exterior tools I have used were always taut and locked strongly, and had very smooth deployment action. I could have my knife tip scraping at something faster than I could pull a phone out of my pocket.

I lost that Wingman but it was quickly replaced by a Wave+. Should you have an eye for tinkering, fixing or tweaking things a leatherman will elevate you at least a few percentage points towards having super powers. I was astounded at how many situations can be handled more effectively if you have a bit of mechanical advantage. And a knife.

Hilleberg tents are amazing quality but they are not light. They can't be because that would impact the quality.

I don't know what you'd consider light but the Akto packs to around 1.3-1.5 kg.

Given that I've been in it during weather reaching up to 35 on the Beaufort scale (~20m/s) with severe rain I feel it packs a fantastic punch for its weight.

I'm sure there are some niche ultra light space age material tents out there.

But that would be like saying a Tesla isn't a good car because it can't reach space.

A solo tent needs to be below 1kg before I'd consider it light.

Maybe it is the lightest tent when considering the weather it can deal with, but this was not mentioned in your original message.

I don't get the analogy with the Tesla going to space? You don't expect cars to fly. What would be the tent equivalent? Using the tent as a boat?

Can you give an argument why we should adhere to your personal standard of a tent being light only if its under 1kg? Is it supported somewhere else? What if someone comes and claims that a tent is light only if its less than 500g?

I never said you have to adhere to my standard. Light is subjective of course. There is no such thing as a light weight standard for tents and if there was it still wouldn't be objective. I base my opinion on what is available in the solo tent market where I look at a combination of price, durability, where it will be used and how many days the hike is. There are not that many tents under 500g so it's a bit too restrictive in my opinion, but someone else could claim that and that would be fine.

I guess we are looking at different use cases for these tents.

I hike inside and around the arctic circle, sometimes during winter time.

That my shelter, that can take the beating that this kind of climate can dish out, weighs only around 1/30th of my total equipment weight makes it an incredible deal.

And subjectively very light.

Yeah I could have framed my original response better.

I have hiked above the arctic circle but not during winter time. Then I would look towards what you are using. ;) You do seem to hike a little heavier than me, but that could be a seasonal thing. When I go for a 10 day summer trip my pack is around 19-23kg, enough stuff to deal with weather around 0C and rain storms.

What setup do you use for new Android apps? I dabbled in building an Android app months ago and sort of gave up because I couldn't decide on the best "framework".

I do native (Java/Kotlin) and Flutter development, for 10 and 2 years respectively. Just this year moving into the Jetpack Compose territory, and enjoying it immensly.

Regarding the question about what you should choose, well that really depends on the problem space and the end goal you have in mind.

If the application is generic, will not really leverage platform specific capabilities and will be made for both Android & iOS I'd say go for Flutter. Here I mean that specific sensors and OS capabilities will not be used, as well as sharing of code for different platforms such as TV, car and wearables.

If the application is ever going to be Android only, I'd say go for the native UI toolchain, which would be Jetpack Compose. The ramp up from 0 to 100 is quick given how much good material is out there to get started (for instance go to and use the Android/Kotlin community slack channels). This route would require you to use Kotlin.

Skip looking into the old view system. Any relevant information from that space will come in time, and the rest wont be relevant anymore.

If you want to create a code base that can be leveraged with web, then go for some of the JS frameworks.

If you do have some piece of framework in mind you want to learn, then use that.

It all depends. Just keep Voltaire's words in mind:

"..best is the enemy of the good"

edit; formatting

Thank you. Follow up question if you have time. For these native Android apps, I'm interested in building apps that have good backward compatibility and thus low maintenance costs. Is backward compatibility easy to achieve with Android apps? If not, what tips can you provide?

Again that depends on how far back you are thinking to be backwards compatible.

Every year the number of users on older apis reduces, and these older users then either jump forward almost to the front (new phones, many low cost versions available today) or at least somewhat to the front (buy newer used or refurbished devices).

As Google has done quite a bit of work to try to solve some of the issues with core OS updates on third party decices (Project Treble for instance), over time the fracturing is getting better (for instance the latest API releases are bringing with them changes to how 3rd party OEMs can bundle their own Linux kernel modules so that the process is simpler and so could extend the possible software update cycles).

But there will always be some fracturing in some respects.

With that out of the way, I have not made apps with lower API requirements than 21 in the last 4 years and starting on one now I set the limit to 23.

This does not bring with it as many headaches as say when I was supporting API 15 onwards.

Google has put a lot of effort into creating tools that take care of much of the biggest headaches (for instance WorkerManager for background task execution and scheduling).

It also really depends on what parts of the platform you are going to use. If you do netwark calls, local data caching and display only then you wont have any problems that need handling.

There is sadly still this lingering sense in the dev community that Android developers need to deal with massive amounts of fragmentation. I would say it is no way as bad as it used to be, and only ever becomes apparent at the edges.

Just follow the guides that Google supplies. They are excellent and take care of explaining each possible pitfall and nuance you might need to take care of.

I recently wrote my first Android (and iOS) app, and decided on React Native. I just wanted to make something quickly, cross platform, and easy to understand -- React Native fit the bill.

No affiliation, but Expo made it very easy and FAST to get up and running for testing and building. Highly recommend it.

I agree on kotlin. It's probably the only language where I feel like the code is practically pseudocode.