skysight-inc/HackerNews huggingface dataset:
Smil's point was more that it is possible to control a tremendous amount of energetic capacity and consequent power (industrial, economic, financial, political, ...) that literally comes out of a hole in the ground.

This also has implications when considering EROEI --- energy returned on energy input.

I mentioned the First Oil Well, Bahrain. It produced at 70,000 bbl/day (not 80k as I'd stated earlier). Typical oil well casing pipe is about 12" in diameter, let's call that 30cm, giving a wellhead area of 700 cm^2. Let's call that 0.1m^2 just to make the maths easier.

That is roughly 55GW/m^2 of continuous energy throughput.

Solar power delivers about 1kW/m^2, 10 MW/hectare, or 1 GW/km^2. Effectively, that's typically achieved for only about 1/3 of a day. I'm not factoring that into the discussion which follows.

The 55 GW of the First Oil Well are equivalent to the peak incident sunlight falling on a region 55 km^2 in area --- about 7.5 km (4.6 mi).

The net solar PV generation is a very small fraction of that, typically less than 10% net efficiency, so you'd need to expand that to 550 km^2, or 23 km ( 14 mi) on a side.

(San Francisco is 11km / 7mi square.)

Yes, oil fields are far larger, they're also far less prevalent, and unevenly distributed. Sunlight tends to be much more evenly distributed.

The notion that there's more than adequate solar energy arriving on Earth is attractive, but potentially dangerous given various factors:

- 2/3 of sunlight falls on oceans rather than land. Capturing this would prove extraordinarily difficult.

- Net of conversion, we'd do well to capture 10% of the incident energy.

- Transmission and storage further reduce energy. Transmission is surprisingly efficient. Storage has proved quite challenging.

- PV solar infrastructure has a lifetime of ~20 years. Put another way, 5% of infrastructure assuming no growth would require replacement each year.

- There are ecological impacts to very-large-scale land-use changes.

- The human population is continuing to grow, and is anticipated to do so through the end of this century.

- Roughly 5 billion people would like to achieve at least an approximation of a Western standard of living.

The US standard of living, based on ~100 quads (quadrillion BTUs) per year, and 330 million people, is about 10 kW.

The global standard of living, based on ~500 quad/yr and 8 billion people, is about 2.3kW. That's an average, and for a huge population, the net energy rate is a fraction of this.

At a US standard of living, 10 kW/person translates to 2,400 quad/year, 4.4 times greater than total present consumption.

At 0.1 kW/m^2, this is the equivalent of 802,000 km^2.

Or about 895 km on a side.

Since I mentioned net production is about 1/3 of nameplace capacity, we actually need 3x the area. So: 2,700,000 km^2, or 1,600 km (1,000 mi) on a side.

That's ... large. But not entirely infeasible.

In truth, population is projected to grow through ~11 -- 16 billions by 2100. And there are other factors which would further diminish net delivered energy. I suspect the global average per-capita power consumption by 2100 will be somewhat below 10 kW/person.
Storing access tokens in Javascript and storing them in a native application have about equal protections - but by far most Javascript apps are left far more susceptible to third party code execution.

The answer is typically to make such credentials incapable of being exfiltrated by adding proof-of-possession, such as the use of MTLS or of the upcoming DPoP mechanism.

Note that preventing exfiltration doesn't prevent a third party from injecting logic to remote-drive use of those tokens and their access sans exfiltration.

While access tokens can be requested with specifically limited scopes of access, a backend server could potentially further control the level of access a front-end has. The problem is that the backend and frontend are typically defined in terms of business requirements. As such, there hasn't been a clear opportunity for standardizing such approaches.

When using a backend, my advice is to be sure you don't just have your API take a session cookie in lieu of an access token. API are typically not constructed with protections from XSRF and the like (or rather, an access token header serves as an XSRF protection while just a session cookie will not).

> Also, if I'm not mistaken, PKCE extension is optional in OAuth 2.0

Correct - although it is strongly recommended by best current practices, including recommending deployments limit/block access to clients which do not use PKCE.

> …and without it you cannot securely use the code flow (as you would have to expose the client secret).

PKCE has nothing to do with client secrets or client authentication. It provides additional strong correlation between the initial front-end request with the following code exchange request.

It was written to support native apps, as many such apps used the system browser for the authorization step and then redirected back into a custom URL scheme. Since custom URL scheme registrations are not regulated, malicious apps could attempt to catch these redirects. PKCE provides a verification that the same client software created both the redirect to the authorization endpoint and the request to the token endpoint. Even if a malicious piece of software got the code, they wouldn't have a way to exchange it for an access token.

Some of the original OAuth security requirements for clients have been found to be poorly implemented, but that PKCE provides equivalent protections against these particular issues. Unlike client-only implementation logic, PKCE support is something that an AS can audit. Hence it being likely that PKCE will be a requirement in future versions of OAuth.
While some ecological disasters are definitely man-made, the Sahara has been mostly the way it is today for the last 10,000 years (source: https://en.wikipedia.org/wiki/Sahara#Desertification_and_pre...). Of course the current climate change will influence whether it will expand in the future, but the "core" Sahara has been there before human influence...
Over representation and privilege, eg, easier admissions to college or hiring. We haven’t ended bigotry, but under the guidance of Democrats and Leftists, created a new system of bigotry — using euphemisms like “equity”.

Which is the same reason White students lie about their race.

https://thehill.com/changing-america/enrichment/education/57...
A Major Ocean Current Is at Its Weakest Point in 1000 Years
From an outside perspective, American system looks more like "right" and "extreme-right", disguised as choice over small-ish policies.
Sadly that's an extreme them-or-us system that's being slowly exported pretty much everywhere else.
Eastern European cities aren't the only examples. Nordic cities (e.g. Stockholm and Copenhagen) are great examples - they have different problems but people are housed. Cities like Berlin don't have a speculative housing market due to excellent renters rights meaning the majority of people rent long term. Finally, Vienna is the poster child for "how to do social housing".
Much oil sands extraction occurs in regions poorly suited to large-scale reliable solar generation.
https://inflationchart.com/income-in-home/?time=10%20years

This isn’t good.
Cubemail is 80% tinymce and queryui on the rendering front. We have different sensibility, Having notifications / autorefresh / working on mobile is more important to me that a predictable, static and stale interface.

About the copy and paste situation, having implemented a text editor myself, JS is of great help to handle copy and paste. Just letting the platform do what it does via the text entry of the copy buffer has some underwhelming behavior that are seen as bugs.
I miss Windows Phone.
> Tab is _never_ a data character.

Until it is. Just like a semicolon for CSV.

> And if return carriage is a data character, you probably shouldn’t use a dsv file in the first place.

Agree.

EDIT:

> I am keeping my tsv

As a solely import-export data format (ie no manual editing) it has some virtue. But at this point you can just use XML, CLIXML or even SQLite *shurg_emoji*
How about comparing knowledge to a foam or foam structure, which is decaying exponentially.
You cannot just dismiss communism based on "human nature", this was an old hat even in 1880.
Annoyingly now diagram in the article, but wikipedia provides more background:
https://en.wikipedia.org/wiki/Atlantic_meridional_overturnin...
Well, PHP approach to features is not really "pragmatic", it has boiled down for decades to basically adding whatever they could rip from somewhere else, without the slightest trace of logic behind it. When they deprecated and removed mysql_* way way more impactful IMHO, it basically broke half of the websites on the web. Was it worth it? Absolutely yes, because mysql_* functions were utter garbage and have caused unmeasurable damage over the years with their shoddy approach to sanitizing. Sometimes you have to atone for your sins, and that's what PHP has been doing in the last few releases.
that's the downside. nobody owns anything, dependencies and deployments become opaque.

i once had a team lead in a quasi monorepo situation tell me straight up to copy-paste some functions i was interested in from their code. they made up some fishy story about deployments. was the story true? did they even know? did anyone know? who even owned it? would they even know?

or the guy who got up in arms because i touched his team's code and didn't write the unit tests that they didn't write when they originally wrote the code.

oh, monorepos.
Yes, outbound only is great for client side and for me table stakes. OpenZiti allows you to make the server side outbound only too. Do you care about Log4Shell or Spring4Shell when your server is dark to the internet? Java Magazine recently did a piece on it as the OpenZiti team 'zitified Springboot' - https://blogs.oracle.com/javamagazine/post/java-zero-trust-o.... We also recently zitified Prometheus - https://openziti.github.io/articles/zitification/prometheus/...... private, outbound-only connectivity natively part of the code.
My experience is identical. I’ve worked for people with no degree, and, outside of my friend group, I have no idea of the formal credentials of most of my peers.

I’ve hired folks at all levels. Degrees are one data point among many when I decide to interview a candidate, rarely discussed when making a hiring decision, and _never_ a factor when making a promotion decision.

If considering formal education to unlock promotion, I would strongly suggest speaking with one or two people with recent, direct experience in the promotion process at your institution. Get familiar with the functional reality of the process (it’s usually more subjective than advertised), ask how credentials are used (they usually aren’t), then go from there.

I will say that I have required education as evidence of commitment when considering applicants who were looking to change careers (that is, I see you have had success in your current role, but go get a cert to demonstrate basic aptitude and show me you are serious about doing this). This was only relevant for the most junior, entry level positions.

As an aside, I’m currently pursuing a teaching credential through WGU, but I have zero expectation that it will provide additional income (quite the reverse!) Rather, I’m pursuing the credential as a forcing function to engage with topics outside of my professional experience, and to provide access to opportunities that are actually formally, legally gated by credentials (teaching in public school in California).
>One solution to this would be to guarantee a unit in any multi family or apartment building to the current resident, and pay for their relocation while the new unit is being built.

You are just increasing the cost of the building's rent with this stuff. You'll have a few birthright units and everything else will be luxury to cover costs. This is the same problem we currently have with affordable units, huge missing middle.
The problem in almost every country with out of control house prices is low interest rates since the dot com crash.

That's where everything went wrong. At 0-1% interest you can get insane mortgages for 90-95% of the value of the property, pushing the price up to where people spend every last cent they can on mortgages, but at $xxxx per month you can easily afford hundreds of thousands of dollars in mortgages.

Raise interest rates (happening), go into recession, crash the market, stop people getting mortgages, house prices will drop insanely fast and hard.

Of course no government wants to do this because it will panic the home owning class. Well - you have to chose at this point. Make it impossible for young people to buy a home, or piss off homeowners.
i don't recall if i ever actually went into a Guitar Center before, but if i did, it obviously wasn't memorable.

but i went into one (again?) a few weeks ago -- in NJ -- and it was like...a fucking riot.

there were like... i don't know. it just seemed like 100 different people were playing a 100 different instruments and people were talking and jamming and wtf.
It's not very good at knowing when something doesn't alias, for example.
E.g. if you do this, the compiler doesn't realize it's safe to do because the array locations are different so I'm not borrowing the specific location mutably more than once. Instead it nags me that I have to split the array into non-overlapping slices.

if (i != j)
swap_items(&mut arr[i], &mut arr[j]);

A contrived example and obviously the same can be achieved in many other ways, most of which the compiler would be happier about - but that's often the case with Rust: a seemingly safe thing isn't quite safe enough for the compiler so you have to do it differently. And that's the main problem of ergonomics in the borrow checker imo.

This is helped enormously by helpful error messages, and there is great progress on fixing little paper cuts and improving the borrow checker to make more valid programs accepted by the borrow checker. But it doesn't contain a massive AI or theorem prover so there will always be situations where you'll need unsafe despite not actually being unsafe, or when you'll do something a bit more contrived than you might have expected.
Right, it's been a few years since I re-read the Tanenbaum, and I got confused over the technical capabilities.

But the core issue remains: they have disabled the SIMs, they have reappropriated the numbers of paying customers.

From one of their employees: «While at the store they can reactivate your account with your old number if it is still available»

When one buys petrol, how can it the seller's business which engines will see it.

In the basicmost terms: if the connection technologies of some devices stop being supported by the infrastructure, what is expected is that the subscriber will deal with it in their own terms - not that the contract is ceased!
Given the house for rent is an investment, it’s obvious who should be taking the loss: the investor.
I think there's definitely something to the neuroplasticity thing. Learning does take longer as we age, that's just a biological fact.

> Man what a frustrating journey it has been ! I keep telling myself I'm a seasoned senior dev...

This right here, that's something you're misunderstanding. Learning something new is supposed to be uncomfortable. To learn most effectively, you want to shape your mental behavior to minimize surprise (i.e. grok things) while shaping your outward behavior to maximize surprise (i.e. challenge / update your understanding). That's frustrating. Even if you've learned other things before.

The only thing you're missing is a healthy set of expectations. Accept and welcome the discomfort, and you'll learn like you've never learned before. Thinking you should be exempt from this just adds internal resistance to an already uncomfortable process.
I love it, can I bring one in Italy?

EDIT Actually I discovered that it is a "gallo cedrone", it's fairly common here in Italy too, no need to import it from Scotland
Some of the worst periods in my life were due to jobs that, in hindsight, I just wasn't suited for. I felt like I had to stay at them, because reasons. But the truth was, I probably could've found something else, if I'd decided to look.

So just remember -- "deciding to look" is often the hardest step, and the easiest to forget. After all, the default is to just keep working at the same job, and to feel bad about yourself.

But that's no way to live life. Seek out happiness, and follow it wherever it leads. I'm rooting for you.
Roughly, people who liked movies you liked, also liked that movie.

If you like Star Wars and Raiders of the Lost Ark, but you haven't seen Ghostbusters, and 94% of people who have seen all three movies and liked the first two also liked Ghostbusters, then it's 94% likely that you'll also like Ghostbusters.

I'm sure it's much more complicated and nuanced, but that's the general idea.
No, never. But we'll try again and next time surely it'll work!
> The point is to only maintain the list of packages via this list.

Except you'll find that if you have more than one person looking after the machine, someone will install a package directly and it'll get removed by the next person to run the script.

If your using something like Ansible, Chef or Puppet then you can do things to make it harder for people to make changes to your machines outside of your configuration management.

> What exactly is the difference between a list of packages expressed like this and a list of packages expressed in puppet's syntax?

The big important differences aren't the list of packages, it's the additional tools around the list of packages that you get. Simply installing a package is trivial, setting up your configuration for those packages you've installed is the real issue that you need to solve - which Ansible, Chef, Puppet, etc solves very well.

The script is probably fine if you're the only one using the machine, keep your list of packages up to date and don't change any of your configurations from the defaults (or have a separate process for managing them).
Using a game engine to write a GUI to the OpenBSD package manager
Browsers are the next Russia - we rely on what they offer because that's the easiest solution nowadays but that all is a huge pile of technical debt waiting to blow up eventually. We should be using a well-engineered cross-platform native UI technology instead.
> I have become too comfortable or "set in my ways" as a dev over the years (decades)

If OP has been working in React and Angular for years and now has trouble learning Vue, it's not due to this. Vue is pretty similar to React.
Biomass production on the other hand, can be carbon negative and generate power from waste that would otherwise get dumped.

So isn't it negative surface area by this metric? Similar to rooftop solar.

Despite this being a ridiculous metric, I feel oil probably loses on it still, if you did a proper well to wheels analysis.

Particularly the step when you turn it into electricity, oil/biomass is going to take a major hit in both energy and and surface area.
Wow the telcos in the US are f'ed, who cares what device you use on your account and when it eventually stops working because there's no 2G or 3G you fix that by getting a new phone with 4G or 5G.

Disabling phones because they're not "approved" is stupid but hey, US telco and stupidity are synonyms
> Who are not a marginalized sexuality by any means.

Heterosexual couples are underrepresented on TV due to institutional bias against them.

That’s the definition of “marginalized”.
You can literally embed private, outbound-only connectivity into your application code using one of the many SDKs - C, Java, Go etc etc... here is a good overview https://ziti.dev/. As you can embed inside you app, you can now build 'zitifications' which is apps which have native, private connectivity embedded both client or server side.

Here are a couple of cool artciles on some we have already done:
- Springboot framework: https://blogs.oracle.com/javamagazine/post/java-zero-trust-o...
- Prometheus: https://openziti.github.io/articles/zitification/prometheus/...
Frameworks change and get in the way when a new version is released. It is most annoying. The underlying WebGL changes much more slowly, and in a much more controlled way with a focus on backward compatibility. So I do the same whenever I can and ignore frameworks to get rid of a dependency. The boilerplate overhead can be encapsulated very well into homemade JS functions that only change when I change them. And JS + WebGL is not really low-level.
Also on oil fields: virtually all are ancient shallow fields.

The Persian Gulf region was also subjected to latitudinal compression, as the African and Asian plates collided, which further concentrate the oil by land area.

If you look at reconstructions of the world from ~150--300 mya, and look at which regions were shallow oceans, those are where you'll find present-day oil reserves (or the spent fields which have already been exhausted).

The United States had largely worked out where its own potential oil reserves might be found by the 1870s / 1880s, based both on surface evidence and geology. This even before accurate age of the earth or understanding of plate tectonics were developed.
Ali, what’s up
I would tell you, but I don't want to give the US Government any ideas.
but shouldn't it strengthen with time and experience?
Why should that be an error? First we are explicitly forcing a string to an integer and then comparing it with type sensitivity to another integer.
> Given that commoditization is a scale, I would say it could be toward that end of the spectrum if we wanted it to be.

Commoditization is only a scale inasmuch as the underlying goods are fungible. Corn is a commodity because nobody cares about differences between individual kernels, but if some process came around that only worked with super-specific kernels, then you'd be reducing the commoditization of corn.

I can, however, think of nothing that would make housing even close to fungible. Views, neighborhoods, neighbors, noise, history, location -- the list of things which are entirely unique per property is higher than basically any other market I can think of.