The batteries regulation[1] doesn't contain such an exemption. The legal argument that iPhones may be exempt goes like this:
- The batteries regulation is a general regulation and article 11 specifically says the following:
> This paragraph shall be without prejudice to any specific provisions ensuring a higher level of protection of the environment and human health relating to the removability and replaceability of portable batteries by end-users laid down in any Union law on electrical and electronic equipment as defined in Article 3(1), point (a), of Directive 2012/19/EU.
- There is a different regulation, the ecodesign regulation for smartphones and tablets[2], that is more specific and therefore might supersede the batteries regulation on this front, which says:
> (ii) manufacturers, importers or authorised representatives may provide the battery or batteries referred to in point (i)(a) only to professional repairers if manufacturers, importers or authorised representatives ensure that the following requirements are met:
> (a) after 500 full charge cycles the battery has, in a fully charged state, a remaining capacity of at least 83 % of the rated capacity;
> (b) the battery endurance in cycles achieves a minimum of 1 000 full charge cycles and after 1 000 full charge cycles the battery has, in a fully charged state, a remaining capacity of at least 80 % of the rated capacity;
But what exactly is a charge cycle? I mean, the effect on a battery being loaded from 0% to 100% and drained to 0% again is vastly different from a battery being charged from 40% to 50% and being used until 40% ten times in a row.
And how many people have the free mental space to manage the charge capacity of their phone?
I plug mine into the charger when I go to bed, and unplug it in the morning when I start my day. I don't have time to think about phone charge levels much beyond that.
Can’t say I really trust that stuff like “charge only when green energy is available”. It’s a nice idea but whenever I’ve used Android devices my expectation was that sometimes I plug in my device at night but it doesn’t really charge and I am not going to pay top dollar and deal with life in a walled garden to have that experience.
Maybe you can do an 80% charge limit on Android the same way I do on my iPad 10?¹ My charger is plugged into a smart plug, and I have an automation written using Apple Shortcuts that turns that smart plug off via Matter whenever the iPad's charge rises above 80%.
I don't know much about Android but assume there must be some way to do similar automations (because I've never seen in any of the Android vs iPhone arguments someone say go with iPhone because of superior automation support).
I recommend going with Matter for the smart plug because if you use the manufacturer's app to control it those often require that you be logged in. The problem with that (beyond any annoyance you might have at needing to make an account to use your device) is that the login might occasionally expire, then your automation breaks.
¹I can't use Apple's charge limit setting because for some reason I can't even guess at when they finally added it to iPadOS they only added it iPads newer than my iPad 10.
I have latest Android on the Pixel 8. I just checked and found it under Settings > Battery > Battery Health
It specifically has an option for 80% (const) or an
"Adaptive Charge" predictive algorithm that charges to 80% and then only fully charges to 100% right before you typically unplug it from the charger.
I also wonder how this is impacted by time. If I have a device that's at 75% capacity at 200 cycles, but it's 7 years old, does that fail to meet these requirements?
Because my experience has been that the cycle count doesn't matter that much as the battery gets old. Old batteries just lose capacity.
That's another valid point: when you just keep a battery around and don't use it, it also loses capacity at a certain point.
So even when you don't use them, you have to babysit lithium-ion batteries. That's why I still love devices with those crappy AA batteries. In general, those have lower capacity, but you can just dump a device into a drawer for 3 years (remember to take the batteries out or use rechargeables) and just put fresh batteries into the device when you need it.
For example, I have those wireless Sennheiser over-ear headphones, which are probably 10+ years old, but they just keep working because they use AAA rechargeables.
> Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.
The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.
> I am not allowed to replace it on my own as it would invalidate the five year long guarantee provided by the manufacturer. Why is this stuff not considered as well?
They're the ones paying for repairs, so it doesn't seem that unreasonable? That said: If you can prove the car is being maintained according to the manufacturer's specifications they can't require you to go to a brand dealership. That's just not necessarily easy to prove.
> facilities were purchased for between 1 million yen and 5 million yen and resold to Chinese buyers for between 40 million yen and as much as 100 million yen depending on location
Those prices seem weird. They were buying entire care homes and hotels for less than the price of a car? I understand they come with obligations, but these businesses were apparently financially ok before the acquisition.
I'm familiar with Japan and find it quite believable.
You may be familiar with the "akiya" phenomenon, where empty houses in the Japanese countryside are sold for a song. The same applies not just to residential homes, but to other buildings as well, and their price tag is very low for the same reason: the property has serious issues and/or has been vacant for years, and will require far more than the initial investment to make habitable.
Here's a fascinating blog post by someone who went poking around the ruins of one hot spring town (Kinugawa) that went through a particularly dramatic boom and bust cycle: https://spikejapan.wordpress.com/2010/06/14/983/
This particular hotel at least appears to have been open until fairly recently, but Google reviews describe the "Showa-era" furnishings (read: 1980s at best), and it's on the fairly grim slate grey Kujukurihama beach 3.5 hours from Tokyo by train: https://maps.app.goo.gl/G53KWyCsmeUy8JyR9
What makes you think these businesses are thriving? It's scams upon scams: the Japanese mastermind buys failing businesses on the cheap, pumps up the price and sells them to Chinese people, who then proceed to use them to essentially scam residence visas from the Japanese government.
Not bankrupt doesn’t mean the company is actually worth anything. A large number of tiny business are still in operation because the owner is willing to work at below market rates to keep it operating.
Re the spikejapan blog: The author’s About page includes this line which describes my experience of the article very accurately, having bailed after a couple of minutes:
“It's a species of anti-blog, as there is no way that you'll get through a post if you suffer from any kind of attention-deficit disorder; even then, you may need a strong cup of coffee and an hour to kill.”
I respect the attempt at belletristic writing, even if it falls a bit short. If they had an editor to rein in some of the thesaurus usage it’d be fine. Not everyone appreciates the style, though.
Your straight up guessing with zero information is ridiculous.
The average apartment cost in Tokyo is a little north of $400k (USD), since the year 2000 or so the value of Tokyo apartments has appreciated somewhere around 3% per year. Apartment prices are ALMOST back to where they were in 1989.
I guess it is a small island after all. Not a great example to extrapolate to more connected economies.
Still, it is twice as expensive per square meter as my European capital city. So looking at it without any historical data it is still much more expensive even with declining population and no immigration.
More like an exception to the rule really as it really has unique conditions as opposed to rest of the world.
> Apartment prices are ALMOST back to where they were in 1989.
You mean when Japan was in an epic price bubble (ie: the imperial palace land alone was worth more than all of California) which was followed by decades of economic stagnation? I'd guess that has impacted their view on real estate to a somewhat unique degree in the world.
And I assume this[1] is the reference to Backblaze? Notably not Hindenburg and more recent, but I believe there is some team overlap and there doesn't seem to be anything else.
> So it's very unlikely we'll see developers build sites that are gated on this API existing.
I think this is an oddly optimistic outlook from someone who until recently worked at Google. A company that has shipped, and probably still ships, lots of sites and versions of sites gated behind "does your user agent say it is Chrome".
> It sounds like it has some security vulnerabilities that the maintainers aren't taking seriously
It may, and they may or may not, but the author hasn't actually reported any. They're explicitly ignoring the security policy and vagueposting instead.
It's very much "I know better, do what I told you despise not thinking a second about any second order effects the change might cause" attitude that is so common with security people
Yeah, ITOps and software teams are totally aware of the second order effects of their shitty software and compliance failures, security are always the wrong ones.
It's not, the maintainer has pointed to that discussion multiple times to the author of the submission, saying they need to resolve that before they can just straight up deprecate authentication methods without any alternatives available to users currently using it.
I'm really confused by this interpretation. I see a single comment by the maintainer, saying:
> That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is).
I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.
#8634 is specifically about a breaking change that occurred in v12. It's literally the first line of what you linked:
> In the v12 release of Forgejo (fixed in v12.0.1) there have been breaking changes that impact third-party authentication sources that use Forgejo as a provider. If you have been affected, please help us assessing the impact ...
There also was feedback saying approximately that they've been burned by security changes in the recent past and don't want to run into similar issues without due consideration.
What it means is here[1]. Anthropic is paying €240k a year and in return they get some marketing in the form of a press release and a website mention, as well as someone to talk to.
So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches.
You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has available and how it is better than the one git has. They may very well be right. It also doesn't matter, because the fact that there's a discussion about what branching method to use really just means Mercurial doesn't solve branches. For close to 20 years the Mercurial website contained a guide that explained only how to have "branches" by having multiple copies of the repository on your system. It looks like the website has now been updated: it doesn't have any explanation about branches at all that I can find. Instead it links to several different external resources that don't focus on branches either. One of them mentions "topic", introduced in 2015. Maybe that's the answer to Git's branching model. I don't care enough to look into it. By 2015 Git had long since won.
Mercurial is a cool toolbox of stuff. Some of them are almost certainly better than git. It's not a better product.
This is so strange, because, at a low level, a branch isn't even a "thing" in git. There is no branch object type in git, it's literally just a pointer to a commit, functionally no different from a tag except for the commands that interact with it.
Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served.
I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against them.
Personally I think it just comes down to the status quo. Git is popular because it's popular, not because it's noticably superior.
> I think there are (or perhaps were) some product issues regarding the specifics of various workflows.
I love jumping in discussions about git branching, because that's a very objective and practical area where git made the playing field worse. Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.
Yes, every commit is prefixed with the branch name. Because, unlike mercurial, git is incapable of storing this in its commit metadata. That's ridiculous, that's obscene, but that's the easiest way to do it with git.
Just because there is one project apparently using this in a way that indicates someone could perceive something as a weakness... It doesn't mean it's a real weakness (nor that it's serious).
You can just not move branches. But once you can do it, you will like it. And you are going to use
git branch --contains COMMIT
which will tell you ALL the branches a commit is part of.
Git's model is clean and simple, and makes a whole lot of sense. IMHO.
> Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.
I'm old enough to have used SVN (and some CVS) and let me tell you branching was no fun, so much that we didn't really do it.
To me mercurials branching is closer to the development process and preserves more information, because it records the original branch a commit was made.
Git does not have such concept. That is a trade off and that trade off works great for projects managed like Linux kernel. But for smaller projects where there is a limited number of people working, the information preserved by mercurial could be very valuable.
It also had some really interesting ideas like change set evolution, which enabled history re-writing after a branch has been published. Don't know its current status and how well it turned out to be..
Just FTR - git /can/ store that information, but it requires human input.
If you rebase the feature branch into the main branch THEN follow it up with the merge commit that records the branch name you store the branches (that have been made a part of main) and can see where they are in your log
Mercurial's notes can become cumbersome if there are a large number in the repository, but, obviously, humans can sort that out if it gets out of hand
It's interesting that branches, which is a marquee feature of git, became less important at the same time as git ate all the other vcs. Outside of OS projects, almost all development is trunk based with continuous releases.
Maybe branching was an important reason to adopt git but now we'd probably be ok with a vcs that doesn't even support them.
Trunk based development is still a hotly debated topic. I personally prefer branches at this point in time, trunk based development has caused me more trouble than it's claimed worth in the past, BUT that could be a me limitation rather than a limitation of the style
Not sure if it's true. I mean, I do agree with the core of it, but how do you even do PRs and resolve conflicts, if there are no branches and a developer cannot efficiently update his code against the last (remote) version of master branch?
Trunk based development has every developer in the company committing straight to main - no PRs, supposedly no merge conflicts (but reality is that main moves fast and if someone else is working in the same files as someone else, there will be merge conflicts)
A middle ground is small PRs where people are constantly rebasing to the tip of main to keep conflicts to a minimum
- The batteries regulation is a general regulation and article 11 specifically says the following:
> This paragraph shall be without prejudice to any specific provisions ensuring a higher level of protection of the environment and human health relating to the removability and replaceability of portable batteries by end-users laid down in any Union law on electrical and electronic equipment as defined in Article 3(1), point (a), of Directive 2012/19/EU.
- There is a different regulation, the ecodesign regulation for smartphones and tablets[2], that is more specific and therefore might supersede the batteries regulation on this front, which says:
> (ii) manufacturers, importers or authorised representatives may provide the battery or batteries referred to in point (i)(a) only to professional repairers if manufacturers, importers or authorised representatives ensure that the following requirements are met:
> (a) after 500 full charge cycles the battery has, in a fully charged state, a remaining capacity of at least 83 % of the rated capacity;
> (b) the battery endurance in cycles achieves a minimum of 1 000 full charge cycles and after 1 000 full charge cycles the battery has, in a fully charged state, a remaining capacity of at least 80 % of the rated capacity;
> (c) the device meets IP67 rating.
[1]: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
[2]: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
reply