They sure as shit do have ads. Have you ever accidentally followed a link using a browser profile that has no ad blocking enabled?
I only rarely browse without some form of content blocking (usually privacy-focused... that takes care of enough ads for me, most of the time). I keep a browser profile that's got no customizations at all, though, for verifying that bugs I see/want to report are not related to one of my extensions.
Every once in a while, I'll accidentally open a link to a news site (or to an archive of such a site) in that vanilla profile. I'm shocked at how many ads you see if you don't take some counter measures.
I just confirmed in that profile: archive.is definitely puts ads around the sites they've archived.
I used to work with people who would reply, editing the subject line to end with something like " ACK. <eom>"
These "reaction" message seem about the same as that, and are no more or less annoying. If it became disruptive, I'd rather ask people to stop than fiddle with my server configuration to try to make it stop.
My instant reaction was: "Wait?! They weren't immutable before?"
I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.
We've had a few issues in the past where a file wasn't updated during the release process, requiring us to re-publish one small change. It's not optimal, but given the nature of our release process being long and complex it's a lot easier to fix the asset in three minutes rather than spend an entire day re-building and re-publishing an entire release, updating our docs, etc. just because of one line in one file that wasn't updated correctly.
I guess I'm just lucky, then, to have only dealt with release processes where it's no big deal to do a bump from 5.0.0 to 5.0.1 so I can address something like that. Some of them were long and complex, but they were scripted to the point where it was uniformly better to jump by a 0.0.1 than risk having two different releases with the exact same version # in the wild.
Any "given" name/ID (IE anything but the full hash) in a distributed VCS has to be mutable - without some single central arbiter of truth it's simply impossible.
I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?
> Revocation in Sigstore. A recent post on this blog notes that signatures alone don’t tell you whether to trust an artifact; for that, you need a verification policy. This verification policy is a much more natural place to handle revocation than the identity layer; see Don’t Panic for an example. This allows us to avoid the scalability problems of global revocation lists (see CRLite for a discussion of these issues). The mantra here is revoke artifacts, not keys.
1. You could delete and re-create releases with the same name
2. You could delete and re-create tags with the same name, even if a release was pointing to that tag already
3. You could delete and re-create an asset that was uploaded to a release without doing any of the above.
By and large none of this is a problem on the surface, but you could imagine someone who gains access to a project's release credentials rebuilding a binary with a backdoor and replacing the existing, published version in the release with their new version after the fact.
An immutable release means that you could only inject that code during the release process by injecting the backdoor into the code itself, and since Github allows you to prevent code from entering a branch except through an approved PR and signed commits, it's possible to make that much more difficult or impractical.
"Before", it was trivial to move or delete tags and edit release assets. The only stable identifier available was the commit hash.
Immutable releases now enable permanently locking tags and releases to make supply chain attacks harder to affect users who are using release assets from before an attack occurred.
The previous behavior is still available by the way, I'm not sure what you meant by "before".
Anyone with the appropriate perms could replace binaries uploaded to the release at will. You could also change which commit a release's tag pointed to by deleting and re-creating the release (the link would end up the same since it just references the tag).
In Java with Maven these have a special suffix, "-SNAPSHOT". So "1.0.0-SNAPSHOT". Releases, like "1.0.0" are immutable once released. I always thought that was a pretty sane model.
Nobody thought about mutable releases being utterly bad _before_?
Baffles me...
As bad as hardware vendors selling products with different chips inside as the same model (hello Cisco -- at least in former times; hello HP, formerly selling at least three different, _incompatible_ laptop power supplies with the same label).
Mutability: surprise, surprise, I'm not what you expected! -- maybe one of IT's worst ideas.
Once in a while someone makes a mistake and it is helpful to just fix it.
I've done it myself, create a release, upload it, download to a different machine and discover it doesn't work there, so fix and retest. Only after all those steps do I hit send on the release announcement. This is a useful workflow (particularly the first time you release when you don't even know what you are doing).
So long as nobody abuses that mutable releases are a great thing. However a tiny minority of people are not trustworthy and so we are forced to take away a great things because of that minority.
Depending on the project, doing a re-release with an appended or updated version number might be a huge hassle. For a small, single-binary program run by an agile team it's pretty trivial to recall a release and publish a replacement, but for larger open-source projects with long, complex, release processes, paying customers, external docs, etc., spending an entire new day doing an entire new release to fix one typo in one word in one file in one artifact is less practical than just re-uploading the file and updating your SHA256SUMS.
i was likely too strong in saying nobody. Though they want immutabilty for theoretical purity reasons not for security which I'm sure is why github is doing this. Still it isn't bad toacknowledge them even if most don't care about their conterns.
> Nobody thought about mutable releases being utterly bad _before_? Baffles me...
Some of us been requesting it as a feature since 2016, just because it wasn't implemented until now doesn't mean even people inside GitHub hasn't thought about it.
It's funny they call it "adding a new layer of supply chain security", when I reported it in August 2015 I got this answer:
> Thanks for the submission. We have reviewed your report and determined that it does not present a security risk. Tags and releases are not directly associated. The author lookup for a given release is done when that release is created and not upon subsequent updates. I can see how that could lead to some confusing behavior. I passed your observations on to our developers to see if we would want to change that behavior in the future. But, given that it does not present a security risk, it is not eligible for reward under the Bug Bounty program.
You would hope so. But how many companies have actually changed their IT policy of outsourcing everything to Tata Consultancy Services (or similar) where a sweaty office in Mumbai full of people who don't give a shit run critical infrastructure?
Jaguar Landrover had production stopped for over a month I think, and 100+ million impact to their business (including a trail of smaller suppliers put near bankruptcy). I'd bet Tata are still there and embedded even further in 5 years.
If AI provides some day-to-day running cost reduction that looks good on quarterly financial statements it will be fully embraced, despite the odd "act of god".
Indeed, that slipped my mind. However the Marks and Spencer hack was also their fault. Just searching on it now it seems there is a ray of hope. Although i have a feeling the response won't be a well trained onshore/internal IT department. It will be another offshore outsourcing jaunt but with better compensation for incompetent staff on the outsourcers side.
"Marks & Spencer Cuts Ties With Tata Consultancy Services Amid £300m Cyber Attack Fallout" (ibtimes.co.uk)
I hope it's on the way, but I don't think the Pioneer Na is yet a sign of this revolution. This detailed review didn't leave me in a hurry to go get one, anyway:
The idea is not that Na-Ion batteries are better than LFPs, they are not. The main goal is to make them dirt cheap.
It seems that $15 per kWh of storage should be achievable with them. At this price, it's trivial to install enough grid-scale storage to completely move off fossil fuels in more southern areas.
Na-Ion batteries are better than LFPs when considered the temperature range between 0C and 0f. In this [0] review, prof hobo demonstrates this is the only reason to by Na-Ion (right now).
I knew what 0°C is in °F since I know the °C to °F conversion rate, but my European self isn't able to assign any actual reference to that, which made it kinda useless to me :)
Sodium ion batteries are typically safer than lithium ion batteries. They operate safely over a wider range of temperatures, and have reduced risk of self-combustion.
Most boosters never provide lifecycle & toxicity statistics b/c it tends to run counter to their utopian narratives. What is the typical lifecycle & toxicity profile for these batteries?
Most contrarians fail to compare their detractions against alternatives such as "maintaining the status quo". Maybe batteries with hazardous chemicals in solid state form inside solid housings aren't particularly net-negative by comparison to most existing casual energy storage alternatives such as internal combustion, at least to most laypeople?
You make a claim without a source and refuse to back it up when asked, yet you are doubling down on your confidence in the initial statement. There's an interesting discussion to be had, but this is not it.
There are several factors to be considered: the actual risk of older and newer systems, the impact, how to mitigate a fire and avoid the worst consequences, and weighing against the alternatives. Especially the latter is somehow always absent in denialist narratives. However, when the alternative is basically heating the planet into a dystopian hellscape, we may accept some negatives of any kind of technology that doesn't put our whole existence at risk.
We need to be real about the downsides yes, but let's also be real and accept we don't have any choice but push forward.
Here is my 1 minute AI powered 'research' btw:
"The fire risk for battery plant storage is not a single, universally agreed-upon percentage, but available data suggests a low and decreasing risk, especially for properly maintained and installed systems. For example, one study found the 2023 risk for home battery systems to be \(0.0049\%\), while another source reports a \(97\%\) drop in large-scale system failures between 2018 and 2023. The risk is influenced by factors like manufacturing quality, installation, and maintenance."
I like that you made a post complaining about people not sourcing their claims and then eight minutes later made a post declining to source your particular claim
I said I don't do free work for strangers on the internet but like I said, let me know when you do your own research. It will be a much better use of time than wasting more keystrokes in this thread.
This whole conversation with measurablefunc has been like seeing somebody get asked for a dollar, loudly yelling “And get a job?!” and then spending an hour trying to convince everyone in the room that they’re Bruce Wayne. I love this website.
Edit: or like seeing somebody get asked for a cookie and then saying “And go to the store? And buy sugar? And eggs? And flour? And drive home and bake them?! Hell no!” and then saying “obviously that meant I have a ton of cookies in my house right now”
Probably the questions about all the batteries you claim are burning. The ones that you read earlier and then said that you can answer.
“I would have to do research to find a list of batteries that burned and the percentage of the batteries that burned and I do not want to do that research”
“I already did the research and have a list of burned batteries and know the percentage of them that burn but I will not share it until you research it and give your findings to me”
“With all this talk of ‘what batteries burned’ and ‘the percentage of the batteries that burned’ I have completely lost track of what anyone wants to know re: my statements about all of the batteries that I claimed are burning”
Buddy the way it works when you don’t know something is you just say that you don’t know it. We all know that you don’t know how many batteries burned or what fractions of them both.
You are trying to do the “get the internet to do your homework for you by posting the wrong answer” Reddit meme trick but being so incredibly off putting that it isn’t working. Nobody is going to do your research for you because everyone can tell that’s what you’re asking them to do.
The idea with really cheap batteries is that they don't need good energy density. You just swap them every so often and put the one you aren't using in the charging rack. You could even carry your own reserve energy with you!
We used to have swappable batteries in virtually all of portable electronics. You could even get them in a rechargeable accumulator format. Virtually all of portable electronics has integrated batteries.
Chinese devices have standardized on taking 18650 "3.7V" cells for this purpose.
We might eventually get back there; maybe the EU will do for e.g. hand tool batteries what they have done for phone chargers and mandate an interchangeable standard.
Yeah but AAs suck, and the newer more advanced batteries all have different voltages and require different charge circuitries so it’s hard to create a new standard for them.
It’s all depends on device size and required capacity. AA is not a bad choice for many cases. And there are other replaceable batteries with higher capacity e.g. 18650.
Most modern devices have an integrated 3.7v Lithium battery so standardisation should be possible but I see no market forces for this - devices with short lifespan (limited by a non-replaceable battery) are more profitable.
That's true for smartphones (I had bad experience with Android from 2 big vendors which stopped updates around end of sales date) but many other battery powered devices don't need regular security patches.
For me, this limitation applies only to my phone. I have plenty of other wireless devices and deliberately prefer devices that can use AA batteries. One reason is that I don't have to manage the multitudes of internal batteries as much and I need only 1 battery charger with batteries always ready to go. And obviously, battery going bad won't make my device useless (My DS4 controller's internal battery went bad in about a year. So I'm sticking with xbox controllers.)
A circuit that accepts the voltage range of lithium ion is probably 90-100% of the way to accepting a range of cell chemistries. And you can put in a half cent identifier chip to say what the charging voltage is.
I don't think the technical difficulties are the problem here.
It is always the case that custom configurations have advantages over other configurations. But standards give a good trade off between performance vs having a large ecosystem. Integrated batteries just add to the e-waste problem.
Li-ion cells are available in AA- and AAA-scaled sizes, e.g. 14500, 10440, plus fractional sizes that can be shorter or longer for the same diameter. If we wanted to not glue batteries into devices, we very well could, but that would make it harder to force purchase of a new device when the consumable component inside it fails.
I think very few manufacturers are optimizing for that. The move to integrated batteries for most portable electronics happened when the price of the battery plus charging ICs became lower than putting in a battery holder. Doing battery holder is currently simply more expensive, design is more complex putting it together is more complex. The cost are not intuitive, you can get 10+ microcontrollers for a price of a single physical on-off switch.
Why do you think AA suck ? It’s the chemistry, not the standard size, voltage or swappability right? 18650 and 21700 also have those assets. Some modern devices let you swap 18650.
Every chemistry outputs a different voltage and requires different charge controllers. So sure we could have created a standard lithium size but it would have just locked us in to one chemistry again which will eventually be obsolete. 18650s are also too bulky for most applications. Usually you want flat rectangles. Another benefit of the proprietary batteries is they can completely fill the space available rather than being constrained by the standard.
Swappable proprietaries are still better than not swappable at all. For my previous phone I managed to order an external charger and several replacement batteries.
My understanding is that it's a poor form factor for lithium ion - which operates at higher voltages, and thus needs an extra voltage regulator to step them down to 1.5V if you're packing them into the AA format (adding cost, reducing capacity, & introducing conversion losses.)
Actually came across this video independently a couple of days ago, and having never come across this gentleman before it was enough to convince me that his analysis is of negligible value of the "beg the conclusion" variety.
To wit, in his review he-
-dismisses environmental concerns with Li
-dismisses safety concerns with Li
-dismissed geopolitical concerns with Li availability. Something something "environmentalists!" (shakes fist at clouds) like with the environmental concerns.
-dismisses economic advances of Na
And then the overwhelming focus of his review is that if you deep freeze the battery, it charges slowly. This becomes the foundation of his criticism. Only firstly it's a self solving issue -- the battery warms as it charges -- but in most situations the battery will be in a heated (or will be self-heating) scenario and at an ideal temperature.
I'm no Na booster, and it seems like an incremental improvement in various dimensions for certain scenarios, but that video adds extraordinarily little value to the space.
I disagree with your conclusion about the video even as I think Na is an incremental improvement. I think the video hits solidly on why the Bluetti Na Pro product is not yet a good overall product. I still think it's promising (and I think the reviewer does too). I can see why you think he's dismissing environmental/safety/geopolitical concerns. But I don't think so; I think he's simply taking the perspective of what's the best product for someone who needs to live with this as a primary power pack that they use. Obviously, someone could weigh the concerns that you mention higher than the functionality of the power pack. But reviewing it in the context of performance doesn't equate to a dismissal of those, IMO.
I only rarely browse without some form of content blocking (usually privacy-focused... that takes care of enough ads for me, most of the time). I keep a browser profile that's got no customizations at all, though, for verifying that bugs I see/want to report are not related to one of my extensions.
Every once in a while, I'll accidentally open a link to a news site (or to an archive of such a site) in that vanilla profile. I'm shocked at how many ads you see if you don't take some counter measures.
I just confirmed in that profile: archive.is definitely puts ads around the sites they've archived.
reply