I used to develop Android professionally (at Dropbox in the 2010s, so I have some familiarity with older Android filesystem APIs) and made a very conscious decision to switch to devx and backend work and get out of Android (as did most of my former Android colleagues). The unending hoops you had to jump through and API changes to keep your app working were too much of a pain.
As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...
Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.
All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.
It sucks that the ongoing maintenance cost for the native mobile platforms is so high. Who wants to develop on top of a platform that is constantly changing out from under you?
It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).
But that's Scott's point. If the OS devs had thought through this from the beginning, app devs wouldn't have to keep dealing with breakage. iOS devs have other issues, but not these.
Apple and Google approached the mobile OS from opposite sides. Apple locked everything down and has gradually been adding access/features. Google left the barn door open, and is now trying to shut it. I know which OS/API I'd rather program against.
Heh, I never worked on iOS but based on what I heard from our iOS team at the time, I don't think iOS was any better. Though a lot of the frustrations back then were largely app review issues rather than API stability, like trying to push out a big feature release or bug fix and getting rejected because the reviewer found a new way to follow 20 links to get from the help center website to a page allowing you to sign up for a subscription outside the app store...
Web might be a better counter example - it started super locked down, but has slowly gained useful functionality like notifications, USB, serial, GPU, etc within the sandbox model. It just encourages more investment over time as new functionality is added, rather than annoying devs as useful functionality (documented or undocumented) is taken away.
iOS doesn't regularly break these mainstay APIs.. but when they do break APIs, they never backport them, unlike Google.
One example of an API where we lost power in exchange for security was UIWebView -> WKWebView.
It can end up being far more annoying than usual, even for smaller APIs, because you must maintain both versions of APIs until you get the green light to raise the minimum permitted iOS version.
In college I hung blackout curtains in my dorm room with conduit - IIRC it was maybe $5 for a pipe that was longer, sturdier, cheaper, and less annoying than the typical telescoping curtain rods (where the curtain always gets caught up on the telescoping edges as you open it).
I also love that you can add structural bends with readily available (and relatively compact) conduit bending tools. Gotta love economies of scale.
Maybe I'm the weird one, but it seems odd NOT to consider ~40,000 deaths in the US each year to be "violent" (often they are gruesome blunt force or crushing injuries involving objects traveling 40+ mph coming to a stop nearly instantaneously). Not to mention the debilitating injuries like TBIs or mobility impairments that leave countless many more people harmed for years later if not the rest of their lives.
Nonetheless, the article doesn't provide evidence to back up the claimed "grift" (doing so would require quantifying the efficacy of the activism against the dollars collected), but appears to primarily be an inflamed rant about terminology they don't like.
I don't feel too strongly about the terminology either way, but I'd hope we can agree that the fact that motor vehicles are the #2 cause of death for most ages of children in the US is something we should fix (especially since other countries have shown that it's a solvable problem - e.g. "stop de kindermoord"), regardless of the name we give that problem.
About 3000 people died from a terrorist attack in 2001. The response was a rapid and dramatic overhaul of national security. Not to even mention an entire unnecessary war that killed even more people.
40,000 people die from cars every year in just one country, and the response is to carry on like that's just fine.
All I ask is for the resources allocated solving problems to be allocated reasonably proportionally to the size of the problem.
> All I ask is for the resources allocated solving problems to be allocated reasonably proportionally to the size of the problem.
Sure, I can agree to this. However it requires you to admit grandma getting run over by Santa’s Ford F-150 isn’t as pressing of a matter as drug overdoses (~110,000/yr), or obesity (~300,000/yr), let alone smoking (~500,000/yr), and that the amount of money required to reduce car fatalities, particularly in already developed cities, makes it prohibitively difficult of a sell. It’s not as simple as selling smaller cars, it requires vast reworking of road infrastructure and understanding of safety.
Heart disease is number one. Cancer is 2. Accidents 3. Stroke 5. Four of the top 5 have some link to cars.
How much heart disease, stroke, or obesity, is caused by people driving everywhere instead of walking or biking?
How many deaths from slow ambulance response times? Cars allow suburbs to exist where people live far away from hospitals. People in cities have traffic. If people lived in densely populated places without cars and traffic, faster emergency response times would save many.
How much heart disease and cancer is caused by the air pollution from fossil fuel burning cars? How many deaths are caused by the natural disasters resulting from the climate impact of cars? Even electric cars are polluting the air with their tires, even moreso than fossil fuel cars do.
How much heart disease or strokes are caused by the noise pollution from cars?
How much heart disease or strokes are caused by the stress people experience while they drive and/or sit in traffic?
Cars are a major root cause of a lot of our public health problems. Not only do they violently kill people directly in vast numbers, they don’t get credit for all the deaths they contribute to indirectly.
We should dramatically redesign our transportation infrastructure so that people do not need cars. Reduce car usage to the point where they are only used when absolutely necessary. This will solve not just one, but several public health problems.
You are genuinely unwell, I suggest seeking professional help if you believe cars are the single root cause of problems in the world. 5 of the top 5 are also related to cellphones (obesity is increased by spending all day on technology, RF is possibly carcinogenic according to the IARC, accidents in tech happen daily that kill people, lights can induce stroke, and Big Tech demand WFH positions come into contact with COVID-19 via forced in-office days) and yet I don’t hear you complaining, despite the objective reality that cellphones are related to more death than even cars, and are even the root cause of most “violent” auto accidents.
Lots of resources are allocated to car safety, and have been since the first cars were built. Some deaths are inevitable. Cars are safer than ever. This whole issue is a manufactured crisis. As a society we have considered cars necessary and relatively safe for like a hundred years. You are more likely to die from diabetes or some other chronic illness than a car accident.
As for comparing car accidents to 9/11, you ought to know better. I don't even think it's worth my time to shred that argument.
Interesting, I'm not sure that colorblindness can be severe enough for that to be a problem. I'm red/green colorblind, but I have no issue with stoplights or LEDs. Things onlystart to get hairy once the spectrum shifts closer to the browns such as forest green or burnished slate.
No wifi - it's web serial so connects locally via the USB connection when you plug the iron (or base station) into your computer. It's only "web" in the sense that it uses a browser and web technologies for the GUI, not "web" as in over the internet or wireless.
Eh, I'm mostly just sad Firefox hasn't implemented it yet. I daily drive Firefox, but switching browsers temporarily still beats installing single-use applications with full local machine permissions by a huge margin. So I've been opting for building web serial companion apps on my own projects as well and it's great (besides Firefox)!
Oh interesting, I'll have to try that polyfill - I've been using web serial for all my projects lately because I hate users having to install anything, but Android has been an annoying gap.
If I were to guess - the issue is that many phone basebands appear (at least) as a serial device, and we all know from late 90s/early 00s dialer scams how bad that can go if some hardware manufacturer forgets to label the serial port in a way that can be detected as "never fucking ever expose this to apps"...
It will almost certainly be a class up, if only because it uses integrated tips that combine heating element, temperature sensor, and tip itself into a single element, rather than having thermally bulky and inefficient interfaces like the FX888d's replaceable separate tips. So you get faster heating and more accurate temperature control.
But there's the rub: there are a TON of USB-C irons that use integrated tips, and most are cheaper than this new iFixit iron, so you can get that class improvement for the same price as your Hakko station, so I'm curious if their improvements are a big enough step up from _those_ irons to justify the price.
On the flip side wouldn't that make replacement tips much more expensive? On my old Hakko station I've replaced the tips several times but the element and sensor seems to be going strong.
They're more expensive, but they tend to last longer (at least for JBC & this new iFixit iron since they lower temperature when not in use), allow much nicer more precise temperature control, and often can have significantly more power output and/or thermal mass (depending on the particular tip). JBC tips in particular can be changed while still hot, one-handed, thanks to their iron holders having a tip puller & holder built-in.
The delta in price isn't that different. Legit Hakko tips for FX888/903/907 are ~$7-10 each. Legit Hakko tips for T12/T15 are only $12-20 apiece. Twice as much, sure, but how many tips do you really go through? We're talking probably sub-$30 over many years in cost delta, for some significant advantages.
Legit JBC tips are closer to $20-40, but those are just a different price tier and much more premium. You can also get knockoff/clone JBC tips for $10 pretty easily, and in my experience they work just fine.
Yes, it makes tips more expensive. However, for the about of improvement in performance, I think it is worth it. I use Hakko T15 tips and they are about $20 each. Cheaper Chinese compatible toys are available and probably are good enough, but I don't replace yours frequently enough to care to find out.
Yeah, boost button was a huge step up when I got my TS100 and now I can't imagine ever buying a new iron without it.
Plus, not having the ability to quickly tune temperature settings on the iron itself seems like a step back as well.
I'd be happy to be proven wrong on these, as iFixit's screwdriver sets were one of those things I needed to use to understand the hype (and then promptly bought my own set), so maybe this is another case of subtle quality you have to see for yourself?
We spent a lot of time tuning it. We've found that temperature settings really aren't needed for most use cases as long as the heating algorithm is responsive enough.
But that may not be for everyone: With the Power Station, changing the temperature is fast and easy with the dial, so you can pick a workflow that works best for you. (You can also change the temperature with the web interface.)
Appreciate the response! I'm still not immediately sold (my TS100 is doing great and I can't justify replacing a perfectly acceptable iron), but I'll have to give it a try sometime because it does look really thoughtfully designed!
I'm not super familiar with this so I could be totally misreading this, but assuming those are operating under part 15 the answer to whether they are guaranteed to continue working seems to be explicitly "no" under NextNav's proposal:
>NextNav does, however, seek the removal of the current requirement that it not cause unacceptable levels of interference to part 15 devices. See Petition at A-6 (proposing to amend § 90.361), A-11 (proposing to add § 90.1410(c)).
As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...
Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.
All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.
[0] Bug 18512473 fixed in https://android.googlesource.com/platform/frameworks/base/+/...
[1] Proof of concept video: https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0