One of the most "real" features of vinyl records that I never really internalised until I started buying a few is that you can take a record out of its sleeve & look at the grooves to see how many tracks is on each side & how long each of the tracks is. You can also "skip" to tracks when playing (much better than tapes ever could) using this same method.
Thanks for sharing, I don’t think I’ve ever seen anything involving James Randi testing someone’s ability and actually verifying their claim, nice to see that not everyone is a bullshit artist!
As a Fairphone owner, I use them for one reason I rarely see mentioned.
I think they're very imperfect phones for a lot of reasons: they're bad value on a pure hardware specs to retail price comparison, their security update support isn't where it could be & the repairability - while best on the market - still has gaps.
However, the rarely mentioned story is their supply chain advocacy initiatives. Not only do they try to source as much of the hardware ethically as they can, their work has also had a broad knock-on effect on the entire industry. Their living wage advocacy for the assembly factories they use has resulted in wage improvements within those supplier companies for employees working on non-FP hardware as well. Their work in Congo with the Fair Cobalt Alliance is a big part of the reason that other companies like Apple are even able to source "certificate recycled" cobalt for their batteries (albeit those certifications are misleading due to the mass balance system, they're still a lot better than nothing).
> I brought it to my local repair shop. The owner had to tell me that they cannot repair Fairphone's, and that, for him, it is one of the worst companies to deal with.
This sounds like an odd & inconsistent story (from the repair shop guy - I'm not doubting your side of this, only his). Why would he need to be dealing directly with the company for any reason other than to purchase replaceable modules which are consumer-available & what would they be giving him trouble with specifically? Unless he's sending all his phones for repair back to the OEMs, but I'm sure that's not the case.
I wouldn't be surprised if some repair shops simply have a "mainstream brands only" blanket policy & don't consider other brands worth the time it takes to read about.
Otherwise you're right that the fingerprint module is specifically a bit of an achilles heel in their repairability. Even leaving aside the fingerprint reader isn't a separate component, it's also unclear to my why they made the decision not to sell the core module for standalone replacement (even if it ended up being quite expensive).
> it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS
> Also, don't do this [...] That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. To many HTML elements can slow the page to a crawl.
A static JS-less page can handle a lot of HTML elements - "HTML bloat" isn't really a thing unless those HTML elements come with performance-impacting behaviour. Which "self-contained" web-components "bringing along their own dependencies" absolutely will.
> shouldn't require an external framework
If you're "bringing along your own dependencies" & you don't have any external framework to manage those dependencies, you're effectively loading each component instance as a kind of "statically linked" entity, whereby those links are in-memory. That's going to bloat your page enormously in all but the simplest of applications.
> Four years later and the model had been discontinued
Which model? Was it the FP1? It sounds like your friend was extremely unlucky - FP2 is 11 years old & there's still (a limited subset of) parts for sale for it (display & camera). FP3 (7yo model) still has all the parts for sale.
That said - I'm critical of another aspect of device longevity: software support. I upgraded from my (still working) FP3 to the FP5 because apps I needed stopped working on the highest version of Android supported by FP3. That Android version is still officially supported by Fairphone & receiving security updates but without major version upgrades the app support can be problematic. Obviously that's ultiamtely the fault of bad app devs, but ultimately it's hard to overcome.
More like google's fault. They made a huge mess of completely different permission and behaviour changes between 11, 12, 13. At least since 14 they have stopped fucking around so much.
It is really much simpler for us to cut off all versions before 12, but it's unfeasible. So many devices still with 10/11. Now we cut off at 8.1, but will increase that every year starting next year as google mandates us an increase of minimum sdk version.
I don't like how companies behave like that and basically push users to upgrade their phones
Garmin in particular makes it mandatory to use their app for SOME connected functionalities (while others work just fine on wifi or wifi tethering).
They unsupported old version of android for the garmin connect app pretty fast (my mom's phone was incompatible within 4 years of its release) while they don't support you to connect older devices on newer phones and say they know it doesn't work.
As a user, I don't care whose fault it is.
I ditched both Google in favour of degooglized android on older Xiaomi and Pixel phones that support custom ROMs, and Garmin for any sport equipment.
My next phone will be a Fairphone if they make something with a smaller screen.
I don't know which app you're doing, but I would most likely permanently just not download it or find an open source alternative if it stopped working for me, as no app is essential.
Pay attention to the user-base, in particular is your app is supposed to work with a web of users.
While i always try to look for open source utility apps (i use several), our userbase simply don't care.
Context: Our apps are means to connect to our devices via BLE, are free and without ads (fuck ads, fuck all ads), no integrity checks. We don't publish the API but we know of a couple of clients that reverse engineered the protocol and made their own. Good for them. (one of them also came by the office to bring a friend and showed us his app that glued together the functionality of several modules from also our competitors. Cool!)
But given what we do our customers are complete normies, doing what google asks us is the path of least resistance, and gets us most audience.
Those who don't want to use the play store can find the APK in the usual sites, don't care.
If i made app for myself i would indeed distribute it differently.
I haven't done Android dev in a while, but I remember the Android SDK offered a 'backwards compatibility pack' - you selected which version you wanted to target, and how old a version you wanted to support (you could go back to like android 5) and it gave you all the polyfills necessary. The only downside was that your app size would balloon to crazy levels.
It's more or less what minimumsdk does, but there may be libraries that require you to bump the minimum.
For example, there are APIs that make feasible something that should be trivial (like autosizing a font based on size, the way it happens in iOS) but they are available from 8.0 so you cut out anything below that.
Or, we use BLE a lot and there are newer methods that makes our life easier but again are not available in older SDK versions
That "officially supported" comes with a huge asterisk though. Security bulletins for old android versions already only include backports of high severity patches. On top of that the device also gets no security patches for firmware or kernel, as the hardware and kernel are eol. The FP5 is also on an eol kernel after less than 3 years, not that they were providing kernel updates in the first place. https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
This is a very long list & is still missing obvious well-known surveillance companies like Experian & who knows how many others. I can imagine the task of documenting this network is going to be pretty intensive.
This is a really great post, concise & clear & educational. I do find the title slightly ironic though when the code example goes on to immediately do "import anthropic" right up top.
(it's just a http library wrapping anthropic's rest API; reimplementing it - including auth - would add enough boilerplate to the examples to make this post less useful, but I just found it funny alongside the title choice)
I came across this Github comunity discussion today - "Unanswered" from April 2023 - & it felt very relevant to current discourse in the context of some recent frontpage submissions here on Claude CLI[0] & comments questioning whether Dependabot is actively maintained[1].
I wonder are we entering into an era of large commercial enterprise SaaS that is simultaneously expensive, in demand & also abandonware.
The post mentions a number of times that leaks happen "all the time", but the only comparative data shown related to this is for historical leaks from AS8048.
Does anyone have data on what the general frequency of these leaks is likely to be across the network?
I’ve seen leaks impact my company directly 4 or 5 times in 4 years, so I would think often enough since we own a /9~ and don’t change our routes too often.
BGP is outside of my skillset, and I'm sure the analysis is fair and accurate. However, had billion dollar US based company Cloudflare detected widespread manipulation of routing tables by the US secret services, I certainly wouldn't trust them to publish it.
I’m pretty confident that the US SIGINT agencies wouldn’t manipulate BGP to redirect traffic somewhere, as such a hijack will ALWAYS leave traces that would be observable by anyone impacted, downstream or upstream.
US SIGINT agencies? They’d just pwn the routers they are interested in. And almost certainly they’ve already done it. Like 10+ years ago.
BGP hijacks are really low-tech and trivial to detect. And competent intelligence agencies don’t do either, unless it comes with enough plausible deniability that it would even be insane to suggest foul play.
I operate a small BGP hobbynet under 2 different AS numbers, and even I keep logs about path changes. Not for any practical purpose, just sheer curiosity.
BGP is a globally distributed and decentralized system. The messages (announcements) propogate virtually across the entire internet. If someone hijacked a route to a prefix that I’ve received, and the path I’ve received is the hijacked one, I’d get that information.
So yes, if that happened, I’d totally expect CloudFlare to publish it, unless they got a NSL. Which they most probably wouldn’t get, as NOTHING about the event would be secret—-it would be out in the open for everyone to see the instant it would happen. There are also tools like https://bgp.tools which operate public route collectors, with the data being publicly available. RIPE has one too.
I was expecting it to be replaced once they announced they were integrating Endor Labs into their GitHub Advanced Security enterprise offerings but all the news I've heard since that announcement has been focused on merging into Microsoft & AI-related layoffs so I presume someone just forgot to turn the Dependabot light off as they were leaving.
reply