HN user
It's not that writing _is_ thinking, but (effective) writing _requires_ thinking. It forces you to take a collection of lose and incoherent thoughts and reify them into an argument that can hold its own weight.
We can't draw conclusions from that study because it's been retracted on the basis that data has been faked.
On the other hand there are other similar studies that reach similar conclusions, and specifically try to control for aerodynamics e.g. [1] which says
The weak positive relationship between vehicle registration year and splat rate suggests that newer vehicles are more efficient at sampling insects than older vehicles.
i.e. they saw more insects on newer cars compared to older ones in the same time period.
In general ecology studies aren't like lab physics, you can't control every possible confounding variable; the systems are too complicated and studies ex-situ have their own limitations. But refusing to engage with the data we do have because it's not perfect isn't going to help you make better decisions, and doesn't represent some moral high ground.
[1] https://cdn.buglife.org.uk/2022/05/Bugs-Matter-2021-National...
1. Why focus on Swifts as opposed to any other species in decline? They state that they are "iconic", so maybe that's the answer? Are they more "iconic" than any other specifies in Scotland?
They are a red-listed species whose population in the UK has declined by two thirds in 30 years. They are also a species for which there's an obvious measure that can be taken to reverse one of the changes which we know has happened over that time (improved building standards reducing the availability of nesting spaces).
If we can't take simple steps to protect swifts I don't think there's much chance that we'll protect anything. Conservation wise, this is really low hanging fruit.
2. Why are these bricks the best solution? Why not take that money that would be spent on bricks and instead preserve land, or just build them dedicated houses elsewhere?
Swifts are extremely site-loyal. You can't just hope that they will move elsewhere. Before buildings they nested in caves and tree cavities. Caves in particular don't move from year to year, so as a result the birds have a strong preference to return to the exact same location where they themselves were born and are slow to colonize other places.
Also your suggestions sound extremely expensive compared to this plan. Swift bricks cost like 30GBP retail. Yes, that's a lot more than the normal house brick they replace, but it's trivial compared to the other costs of building a house.
3. Why does this need to be done via government mandate versus voluntarily asking people to build Swift housing in existing buildings or land?
That's more or less the current situation in England, and perhaps unsurprisingly it's extremely rare for developers to actually install swift bricks. Indeed it's relatively uncommon for developers to actually follow through on their existing legally mandated ecological commitments [1].
Making something mandatory everywhere is also cheaper than making it only required in certain places: it eliminates all the bureaucracy around deciding whether this or that development is in the right area, and makes it extremely easy to follow and enforce the rules.
Now it is possible that the lack of nest sites isn't the dominant factor in the decline of swifts. For example it could also be related to the decline in flying insects, or changing weather patterns induced by climate change. We aren't really sure [2], however from that study: "it would be precautionary for conservation efforts to continue to focus on ensuring that safe and productive nesting sites are in sufficient supply", and we also know that the swift bricks will be used by many other bird species as well as swifts.
[1] https://wildjustice.org.uk/lost-nature-report/ [2] https://www.bto.org/our-work/science/publications/papers/dem...
(I work on Firefox Web Compatibility)
If you have specific sites that aren't working, please let us know and we can investigate and try to fix them.
The usual reporting channels are using https://webcompat.com or the "Report Broken Site" tool in the Firefox menu. Of course I"m also happy to take bug reports here if you (or anyone else) have them.
I think if prediction 1 is true (that it becomes cheap to clone existing software in a way that doesn't violate copyright law), the response will not be purely technical (moving to thin clients, or otherwise trying to technically restrict the access surface to make reverse engineering harder). Instead I'd predict that companies look to the law to replace the protections that they previously got from copyright.
Obvious possibilities include:
* More use of software patents, since these apply to underlying ideas, rather than specific implementations.
* Stronger DMCA-like laws which prohibit breaking technical provisions designed to prevent reverse engineering.
Similarly, if the people predicting that humans are going to be required to take ultimate responsibility for the behaviour of software are correct, then it clearly won't be possible for that to be any random human. Instead you'll need legally recognised credentials to be allowed to ship software, similar to the way that doctors or engineers work today.
Of course these specific predictions might be wrong. I think it's fair to say that nobody really knows what might have changed in a year, or where the technical capabilities will end up. But I see a lot of discussions and opinions that assume zero feedback from the broader social context in which the tech exists, which seems like they're likely missing a big part of the picture.
Power in general.
Your time-average power budget for things that run on phones is about 0.5W (batteries are about 10Wh and should last at least a day). That's about three orders of magnitude lower than a the GPUs running in datacenters.
Even if battery technology improves you can't have a phone running hot, so there are strong physical limits on the total power budget.
More or less the same applies to laptops, although there you get maybe an additional order of magnitude.
China has now had flat CO2 emissions for two years, and experienced a decline in overall CO2 emissions during 2025[1]. Part of this is that they're deploying way more renewables than basically any other large economy [2].
They've also pivoted their industrial strategy so that basically the entire green energy sector depends on Chinese supply chains. This is significantly contributing to their economic growth [3].
I don't know to what extent taxation in Europe contributed to China's decision making here, but it presumably created an market for green energy and therefore helped solidify the economics.
This is of course not to say that there's nothing to criticize in China's environmental policies; there certainly is. But the trope of "why should we do anything because China won't" turns out to be spectacularly ill-informed. Indeed I think it makes more sense to ask the opposite: what are the likely consequences now that China has positioned itself as the global centre of green energy, and what should other countries be doing to ensure that they're not left behind?
[1] https://www.carbonbrief.org/analysis-chinas-co2-emissions-ha... [2] https://www.carbonbrief.org/g7-falling-behind-china-as-world... [3] https://www.carbonbrief.org/analysis-clean-energy-drove-more...
To be clear: I don't think it will happen.
But the point of comparison is something like the HTML specification. That's supposed to be a document that is detailed enough about how to create an implementation that multiple different groups can produce compatible implementations without having any actual code in common.
In practice it still doesn't quite work: the specification has to be supplemented with testsuites that all implementations use, and even then there often needs to be a feedback loop where new implementations find new ambiguities or errors, and the specification needs to be updated. Plus implementors often "cheat" and examine each other's behaviour or even code, rather than just using the specification.
Nevertheless it's perhaps the closest thing I'm familiar with to an existing practice where the plan is considered canonical, and therefore worth thinking about as a model for what "code as implementation detail" would entail in other situations.
it's foolish to fight the future
And yet, the premise of the question assumes that it's possible in this case.
Historically having produced a piece of software to accomplish some non-trivial task implied weeks, months, or more of developing expertise and painstakingly converting that expertise into a formulation of the problem precise enough to run on a computer.
One could reasonably assume that any reasonable-looking submission was in fact the result of someone putting in the time to refine their understanding of the problem, and express it in code. By discussing the project one could reasonably hope to learn more about their understanding of the problem domain, or about the choices they made when reifying that understanding into an artifact useful for computation.
Now that no longer appears to be the case.
Which isn't to say there's no longer any skill involved in producing well engineered software that continues to function over time. Or indeed that there aren't classes of software that require interesting novel approaches that AI tooling can't generate. But now anyone with an idea, some high level understanding of the domain, and a few hundred dollars a month to spend, can write out a plan can ask an AI provider to generate them software to implement that plan. That software may or may not be good, but determining that requires a significant investment of time.
That change fundamentally changes the dynamics of "Show HN" (and probably much else besides).
It's essentially the same problem that art forums had with AI-generated work. Except they have an advantage: people generally agree that there's some value to art being artisan; the skill and effort that went into producing it are — in most cases — part of the reason people enjoy consuming it. That makes it rather easy to at least develop a policy to exclude AI, even if it's hard to implement in practice.
But the most common position here is that the value of software is what it does. Whilst people might intellectually prefer 100 lines of elegant lisp to 10,000 lines of spaghetti PHP to solve a problem, the majority view here is that if the latter provides more economic value — e.g. as the basis of a successful business — then it's better.
So now the cost of verifying things for interestingness is higher than the cost of generating plausibly-interesting things, and you can't even have a blanket policy that tries to enforce a minimum level of effort on the submitter.
To engage with the original question: if one was serious about extracting the human understanding from the generated code, one would probably take a leaf from the standards world where the important artifact is a specification that allows multiple parties to generate unique, but functionally equivalent, implementations of an idea. In the LLM case, that would presumably be a plan detailed enough to reliably one-shot an implementation across several models.
However I can't see any incentive structure that might cause that to become a common practice.
But at a national level the data is compelling. I'm convinced by the Environmental Kuznets Curve.
Which data do you find compelling?
For people who don't know the Environmental Kuznets Curve is basically the hypothesis that as economies grow past a certain they naturally start to cause less environmental damage.
As far as I can tell the main empirical evidence in favour of this is the fact that some western countries have managed to maintain economic growth whilst making reductions to their carbon emissions. This has, of course, partially been driven by offshoring especially polluting industries, but also as a result of technological developments like renewable energy, and BEVs.
On the other hand, taking a global sample it's still rather clear that there's a strong correlation between wealth and carbon emissions, both at the individual scale and at the level of countries.
It's also clear that a lot of the gains that have been made in, say, Europe have been low-hanging fruit that won't be easy to repeat. For example migrating off coal power has a huge impact, but going from there to a fully clean grid is a larger challenge.
We also know that there are a bunch of behaviours that come with wealth which have a disproportionately negative effect on the environment. For example, rich people (globally) consume more meat, and take more flights. Those are both problems without clear solutions.
(FWIW I agree that solar power is somewhat regressive, but just for the normal "Vimes Boots Theory" reasons that anyone who is able to install solar will save money in the medium term. That requires the capital for the equipment — which is rapidly getting cheaper — but also the ability to own land or a house to install the equipment on. The latter favours the already well off. There are similar problems with electric cars having higher upfront costs but lower running costs. The correct solution is not to discourage people from using things, but to take the cost of being poor into account in other areas of public policy).
I said nothing about a monotonic relationship.
You made a scale-free claim about increasing greenness with increasing CO2 concentration. That implies a monotonic relationship.
The only debate is over what might happen in the future, which, again, is fortune telling
The idea that using models of physical systems to predict their future evolution is "fortune telling" will surprise many scientists. Indeed, you yourself have proposed a simple model and used it to make a prediction about the future ("the world will be greener in a high-CO2 environment"), and used linear extrapolation of the past to justify the adequacy of your model.
That's not necessarily a bad starting point, but when actual studies with more complex models show different behaviours you should consider there's a possibility you're over-confident in your predictions.
Anyway, I suspect this conversation has become rather pointless. It's always unclear online to what extent people are engaging in good faith, but if it was then I'm rather sure you've now mentally pigeonholed me as a "doomer" who can't be reasoned with.
you can't easily separate out CO2 concentration from the other impacts of increased CO2 > I never said you could?
I took the fact that you explicitly mentioned "high-CO2 environment" and claimed there was no room for argument over the "fact"s as an indication that you were trying to separate out the impact of CO2 from other factors caused by climate change such as heat stress and drought. If that wasn't the case then apologies for misunderstanding.
That paper is talking about a net reduction in biomass due to projected losses in places with temperature increases exceeding 10 degrees C.
The abstract says:
| with great biomass reductions in regions where mean annual temperatures exceeded 10 °C
Unless the abstract is especially badly written that suggests that it's not 10°C _change_ but 2°C change leading to biomass loss in areas that are already at 10°C on average.
IPCC report
Thanks, that's a useful reference! Do you have a link to the final report? That one seems to be a draft and I didn't find the right published version (but there are many so I'm sure I'm missing it).
I note the paragraph you quoted concludes:
The increased greening is largely consistent with CO2 fertilization at the global scale, with other changes being noteworthy at the regional level (Piao et al., 2020); examples include agricultural intensification in China and India (Chen et al., 2019; Gao et al., 2019) and temperature increases in the northern high latitudes (Kong et al., 2017; Keenan and Riley, 2018) and in other areas such as the Loess Plateau in central China (Wang et al., 2018). Notably, some areas (such as parts of Amazonia, central Asia, and the Congo basin) have experienced browning (i.e., decreases in green leaf area and/or mass) (Anderson et al., 2019; Gottschalk et al., 2016; Hoogakker et al., 2015). Because rates of browning have exceeded rates of greening in some regions since the late 1990s, the increase in global greening has been somewhat slower in the last two decades
So it sounds like a combination of the CO2 increases up to about the year 2000, along with agricultural intensification and various other factors have indeed increased the amount of plant cover, but we are already seeing changes to that picture with further rises to CO2 levels.
You spent a lot of words arguing with me about things I didn't say.
Well you started with
The world will be greener in a high-CO2 environment. There’s no legitimate argument over that fact.
And my central point is that the model you're implying there is one in which there's a monotonic relationship between CO2 levels and plant growth. However in reality things are clearly more complex than that, and there is indeed legitimate argument over what factors are dominant in different scenarios.
Your claim that things will only change over long-enough timescales so that you don't have to worry about also seems to lack evidence. In systems with significant feedback loops it seems dangerous to assume that changes will only happen slowly unless you're very confident that you fully understand all the system dynamics. With climate change it's clear that we don't fully understand the system, and some changes are happening faster than earlier models predicted. So _maybe_ we have a few centuries to figure out how to move global agriculture to northern latitudes, and deal with more variable conditions, but from a risk-analysis point of view it seems like a rather poor strategy.
The world will be greener in a high-CO2 environment. There’s no legitimate argument over that fact.
However it's important to remember that world isn't a high school physics experiment, and you can't easily separate out CO2 concentration from the other impacts of increased CO2:
| Climate change can prolong the plant growing season and expand the areas suitable for crop planting, as well as promote crop photosynthesis thanks to increased atmospheric carbon dioxide concentrations. However, an excessive carbon dioxide concentration in the atmosphere may lead to unbalanced nutrient absorption in crops and hinder photosynthesis, respiration, and transpiration, thus affecting crop yields. Irregular precipitation patterns and extreme weather events such as droughts and floods can lead to hypoxia and nutrient loss in the plant roots. An increase in the frequency of extreme weather events directly damages plants and expands the range of diseases and pests. In addition, climate change will also affect soil moisture content, temperature, microbial activity, nutrient cycling, and quality, thus affecting plant growth.
[https://www.mdpi.com/2073-4395/14/6/1236]
In global models of climate change the overall impact on plant growth is significant, but not positive:
| Global above ground biomass is projected to decline by 4 to 16% under a 2 °C increase in climate warming
[https://www.pnas.org/doi/10.1073/pnas.2420379122]
Certainly it’s more favorable for growth of plants that make food
That does not seem to be what agricultural researchers believe:
| In wheat a mean daily temperature of 35°C caused total failure of the plant, while exposure to short episodes (2–5 days) of HS (>24°C) at the reproductive stage (start of flowering) resulted in substantial damage to floret fertility leading to an estimated 6.0 ± 2.9% loss in global yield with each degree-Celsius (°C) increase in temperature
| Although it might be argued that the ‘fertilization effect’ of increasing CO2 concentration may benefit crop biomass thus raising the possibility of an increased food production, emerging evidence has demonstrated a reduction in crop yield if increased CO2 is combined with high temperature and/or water scarcity, making a net increase in crop productivity unlikely
| When the combination of drought and heatwave is considered, production losses considering cereals including wheat (−11.3%), barley (−12.1%) and maize (−12.5%), and for non-cereals: oil crops (−8.4%), olives (−6.2%), vegetables (−3.5%), roots and tubers (−4.5%), sugar beet (−8.8%), among others
Notice that it says "almost all programs" and not "almost all _C_ programs".
I think if you understand the meaning of "crash" to include any kind of unhandled state that causes the program to terminate execution then it includes things like unwrapping a None value in Rust or any kind of uncaught exception in Python.
That interpretation makes sense to me in terms of the point he's making: Fil-C replaces memory unsafety with program termination, which is strictly worse than e.g. (safe) Rust which replaces memory unsafety with a compile error. But it's also true that most programs (irrespective of language, and including Rust) have some codepaths in which programs can terminate where the assumed variants aren't upheld, so in practice that's often an acceptable behaviour, as long as the defect rate is low enough.
Of course there is also a class of programs for which that behaviour is not acceptable, and in those cases Fil-C (along with most other languages, including Rust absent significant additional tooling) isn't appropriate.
As someone who's been quite heavily involved with web-platform-tests, I'd caution against any use of the test pass rate as a metric for anything.
That's not to belittle the considerable achievements of Ladybird; their progress is really impressive, and if web-platform-tests are helping their engineering efforts I consider that a win. New implementations of the web platform, including Ladybird, Servo, and Flow, are exciting to see.
However, web-platform-tests specifically decided to optimise for being a useful engineering tool rather than being a good metric. That means there's no real attempt to balance the testsuite across the platform; for example a surprising fraction of the overall test count is encoding tests because they're easy to generate, not because it's an especially hard problem in browser development.
We've also consciously wanted to ensure that contributing tests is low friction, both technically and socially, in order that people don't feel inclined to withhold useful tests. Again that's not the tradeoff you make for a good metric, but is the right one for a good engineering resource.
The Interop Project is designed with different tradeoffs in mind, and overcomes some of these problems by selecting a subsets of tests which are broadly agreed to represent a useful level of coverage of an important feature. But unfortunately the current setup is designed for engines that are already implementing enough feature to be usable as general purpose web-browsers.
In addition, the colleges have a lot of data about the people they interview and how well they do during the degree programme.
My understanding (based on a discussion with one Natural Sciences admissions tutor at one Cambridge college nearly 20 years ago, so strictly speaking this may not be true in general, but I'd be surprised if it wasn't common) is that during the admissions process, including interviews, applicants are scored so they can be stack-ranked, and the top N given offers. Then, for the students that are accepted, and get the required exam results, the college also records their marks at each stage of their degree. To verify the admissions process is fair, these marks are compared with the original interview ranking, expecting that interview performance is (on average) correlated with later degree performance.
I don't know if they go further and build models to suggest the correct offer to give different students based on interview performance, educational background, and other factors, but it seems at least plausible that one could try that kind of thing, and have the data to prove that it was working.
Anyway my guess is that of the population of people who would do well if they got in, but don't, the majority are those whose background makes them believe it's "not for the likes of me", and so never apply, rather than people who went to private schools, applied, and didn't get a place.
(also a Cambridge alumni from a state school, FWIW),
It's true, see https://www.carbonbrief.org/factcheck-why-expensive-gas-not-...
From that article:
The UK’s electricity market operates using a system known as “marginal pricing”. This means that all of the power plants running in each half-hour period are paid the same price, set by the final generator that has to switch on to meet demand, which is known as the “marginal” unit.
While this is unfamiliar to many people, marginal pricing is far from unique to the UK’s electricity market. It is used in most electricity markets in Europe and around the world, as well as being widely used in commodity markets in general.
The thing that's unique about the UK is that the marginal price is almost always (98% of the time) set by the price of gas. That means when the gas price increases, the wholesale price of electricity, and hence consumer bills, increase in direct response.
Of course the situation is also made worse by the fact that gas is used directly for heating and cooking in a high proportion of British homes.
Yes! It's a rare example of an app that instead of trying to capture your attention into a virtual environment, helps you to direct it outwards into the real world.
The sound id in particular is just an amazing way to really extend what's possible for most people, and provides an on-ramp for people to identify more birds by ear alone (and in general to pay more attention to sound when in nature).
I might argue that Merlin — and especially eBird — lean a bit to heavily to the competitive "high scores" view of birding; given the impact of climate change on bird populations, encouraging people to travel the world and see as many species as possible is clearly problematic.
But that's a minor quibble, and Merlin remains one of the few apps I'd unconditionally recommend to anyone with the faintest chance they'd use it.
Gecko and Firefox have been using Bugzilla for more than 25 years at this point. There's a lot of internal workflows, tooling and processes that are really dependent on the specific functionality in Bugzilla. I think it would be an extremely high risk project to try and replace Bugzilla with GitHub issues.
That said, there are also other teams and projects who do use GitHub for issue tracking. However the closer to Firefox/Gecko you are the harder this gets. For example it's hard to cross-reference GitHub issues with Bugzilla issues, or vice versa. I've seen people try to build two-way sync between GitHub and Bugzilla, but there are quite considerable technical challenges in trying to make that kind of cross-system replication work well.
However your point that GitHub makes issue submission easier for people who aren't deeply embedded in the project is a good one. I'm directly involved with webcompat.com, which aims to collect reports of broken sites from end users. It's using a GitHub issue tracker as the backend; allowing developers to directly report through GitHub, and a web-form frontend so that people without even a GitHub account can still submit reports (as you can imagine quite some effort is required here to ensure that it's not overwhelmed by spam). So finding ways to enable users to report issues is something we care about.
However, even in the webcompat.com case where collecting issues from people outside the project is the most important concern, we've taken to moving confirmed reports into bugzilla, so that they can be cross-referenced with the corresponding platform bugs, more easily used as inputs to prioritization, etc. That single source of truth for all bugs turns out to be very useful for process reasons as well as technical ones.
So — (again) without being any kind of decision maker here — I think it's very unlikely that Firefox will move entirely to GitHub issues in the foreseeable future; it's just too challenging given the history and requirements. Having some kind of one-way sync from GitHub to Bugzilla seems like a more tractable approach from an engineering point of view, but even there it's likely that there are non-trivial costs and tradeoffs involved.
This is all true, but as the sibling says, not really related to the change discussed here.
Firefox does indeed have a large CI system and ends up running thousands of jobs on each push to main (formerly mozilla-central), covering builds, linting, multiple testsuites, performance testing, etc. all across multiple platforms and configurations. In addition there are "try" pushes for work in progress patches, and various other kinds of non-CI tasks (e.g. fuzzing). That is all run on our taskcluster system and I don't believe there are any plans to change that.
Again, I can only comment from the perspective of a user; I haven't worked on the VCS infrastructure.
The obvious generic challenges are availability and security: Firefox has contributors around the globe and if the VCS server goes down then it's hard to get work done (yes, you can work locally, but you can't land patches or ship fixes to users). Firefox is also a pretty high value target, and an attacker with access to the VCS server would be a problem.
To be clear I'm not claiming that there were specific problems related to these things; just that they represent challenges that Mozilla has to deal with when self hosting.
The other obvious problem at scale is performance. With a large repo both read and write performance are concerns. Cloning the repo is the first step that new contributors need to take, and if that's slow then it can be a dealbreaker for many people, especially on less reliable internet. Out hg backend was using replication to help with this [1], but you can see from the link how much complexity that adds.
Firefox has enough contributors that write contention also becomes a problem; for example pushing to the "try" repo (to run local patches through CI) often ended up taking tens of minutes waiting for a lock. This was (recently) mostly hidden from end users by pushing patches through a custom "lando" system that asynchronously queues the actual VCS push rather than blocking the user locally, but that's more of a mitigation than a real solution (lando is still required with the GitHub backend because it becomes the places where custom VCS rules which previously lived directly in the hg server, but which don't map onto GitHub features, are enforced).
[1] https://mozilla-version-control-tools.readthedocs.io/en/late...
(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
Note that biofuels aren't especially environmentally friendly, even just considering carbon emissions. See e.g. [1], which makes the most optimistic possible assumption by ignoring land use changes and still concludes "the reductions for most feedstocks are insufficient to meet the GHG savings required by the EU Renewable Energy Directive" (second generation biofuels may do better, but that isn't clear). Also ignoring land use changes is a very bad asssumption; if your plan is to run global shipping (or other industries) on biofuels it seems highly implausible that it's not going to end up with more land overall used for growing crops. If that's land that could otherwise be sequestering carbon (e.g. drained peat bogs, which have the advantage of being highly fertile), then it's clearly going to be a significant contribution to carbon emissions (not to mention the ecological impacts of converting yet more land to agriculture).
[1] https://royalsocietypublishing.org/doi/10.1098/rspa.2020.035...
I think there is a lot of truth in this, but presented in a way that misses some nuance.
It's true that if your goal is to regenerate native forest, which it generally[+] should be where that's an option, then it's indeed true that you want to allow existing forest to regenerate as naturally as possible. The problem in these cases is either land use (land is used for forestry / agriculture / etc. so there's nowhere for new trees to grow) or over-grazing (either by livestock such as sheep or by high populations of wild herbivores such as deer). In those cases you need to solve the underlying problems rather than just counting the number of saplings in the ground (in a heavily browsed area planting may have the advantage that you tend to put in tree guards. Ideally one could instead install appropriate fencing around the entire area to reduce herbivore numbers below the problematic levels).
However you aren't always in that scenario. For example if you're in a landscape with few seed sources then natural regeneration might take an implausibly long time. An extreme example of that would be "regreen the desert" type projects where you need to bootstrap the conditions for tree growth by putting in a lot of trees in a short space of time, although those have a high failure rate. You might also be worried that natural regeneration is too slow in the face of changing climatic conditions, and want to plant trees right for the anticipated climate 100 years hence (although that itself is likely to be controversial).
And of course frequently in the real world tree-planting projects have goals totally unrelated to climate change e.g. just forestry, and as such one shouldn't expect those things to be especially good for the climate, or at all good for biodiversity.
Anyway, I like the idea of companies dedicating part of their revenue to tackling severe global problems like climate change. But I tend to agree that Ecosia's continued focus on tree planting as their headline activity makes them look a bit naive to the audience that is likely to be most receptive to changing products specifically for environmental reasons. Hopefully some of the other project types they're moving into look better in the details than just tree planting.
[+] But not always of course. Converting peat bog to woodland, for example, is going to reduce its effectiveness as a carbon store, and likely reduce biodiversity as well.
Well the truth is it's both.
We had to change Firefox so it could be automated with WebDriver BiDi. The Puppeteer team had to change Puppeteer in order to implement a WebDriver BiDi backend, and to enable specific support for downloading and launching Firefox.
As the article says, it was very much a collaborative effort.
But the announcement is specifically about the new release of Puppeteer, which is the first to feature non-experimental support for Firefox. So that's why the title's that way around.
There's an issue open for this on the WebDriver BiDi issue tracker.
We started with WebSockets because that supports more use cases (e.g. automating a remote device such as a mobile browser) and because building on the existing infrastructure makes specification easier.
It's also true that there are reasons to prefer other transports such as unix domain sockets when you have the browser and the client on the same machine. So my guess is that we're quite likely to add support for this to the specification (although of course there may be concerns I haven't considered that get raised during discussions).
Is it possible to now use Puppeteer from inside the browser?
Talking about WebDriver (BiDi) in general rather than Puppeteer specifically, it depends what exactly you mean.
Classic WebDriver is a HTTP-based protocol. WebDriver BiDi uses websockets (although other transports are a possibility for the future). Script running inside the browser can create HTTP connections and create websockets connections, so you can create a web page that implements a WebDriver or WebDriver BiDi client. But of course you need to have a browser to connect to, and that needs to be configured to actually allow connections from your host; for obvious security reasons that's not allowed by default.
This sounds a bit obscure, but it can be useful. Firefox devtools is implemented in HTML+JS in the browser (like the rest of the Firefox UI), and can connect to a different Firefox instance (e.g. for debugging mobile Firefox from desktop). The default runner for web-platform-tests drives the browser from the outside (typically) using WebDriver, but it also provides an API so the in-browser tests can access some WebDriver commands.
That is certainly true of most consumer devices i.e. phones and laptops. For example Dell estimate that 85% of the lifetime emissions for their XPS systems come from manufacture [1] and Apple claim 79% for an 14 inch macbook.
For beefy desktops or servers using hundreds of watts on a continuous basis the situation is rather different e.g [3] which is a Dell estimate for a Precision 7000 series tower showing 74% of emissions attributed to use.
This makes sense: if we assume 700kg of carbon emissions to construct a server, but 300W of continuous power draw during use (seems fairly conservative, especially including cooling) then with the US grid intensity of 0.39 kg CO2e/kWh we find that the manufacturing emissions match the usage emissions over ~250 days of use.
Of course the actual numbers depend heavily on precise circumstances; a data center in an area with less carbon intensive electricity will have a correspondingly lower carbon footprint.
So _as a consumer_ it's true that the biggest contribution is not directly in the usage of the (local) device, but in creating that device in the first place: you're almost always better off keeping a device for longer rather than replacing it with a more power efficient one. But on the server side that isn't the case: the emissions due to operating the data center are also substantial. Plus increased demand on the server side also increases the number of servers manufactured and deployed.
Historically improved hardware power efficiency has meant that carbon emissions have increased slower than compute. So I'm somewhat skeptical when I see articles claiming huge factor increases in the overall carbon intensity of the internet in the near term. _However_ that's not a law of nature, and new technologies that cause a step change in demand for server-side compute could indeed dramatically increase the carbon emissions of the internet.
[1] https://www.dell.com/en-uk/dt/corporate/social-impact/advanc... [2] https://www.apple.com/environment/pdf/products/notebooks/14-... [3] https://www.dell.com/en-uk/dt/corporate/social-impact/advanc...
Work with attributes whose name doesn't match the XML Name production.
That can be a real concern in some cases (it came up recently in the context of "how do I move all the attributes on node A to node B, given that node A's attributes can be anything that can be created by the HTML parser?" c.f. https://software.hixie.ch/utilities/js/live-dom-viewer/?save... )
Technically the difference between "net zero" and "carbon neutral" is supposed to be that "net zero" first eliminates all but "residual" emissions, and only then depends on offsets, whereas "carbon neutral" is more like what you describe (no required emissions cuts; possible to just buy — often dubious — offsets).
Science Based Targets Initiative for example requires companies signing up to their scheme to have credible plans to cut emissions by ~50% by 2030 and 90% by 2050 to claim that they're aiming for "net zero" [1] (SBTI itself was recently in the news because employees felt that recent policy changes leaned too heavily on offsetting; I don't really know what the current situation there is).
In practice usage of these terms my not be well regulated, so it's always worth checking out exactly whose definitions are being used.
[1] sciencebasedtargets.org/blog/net-zero-jargon-buster-a-guide-to-common-terms