skysight-inc/HackerNews huggingface dataset:
First of all solar thermal is still intermittent and subject to weather and seasonal fluctuations. It has a built in thermal battery so it's consistent on a 24 hour basis, but it's still a variable source of energy.

Cost is a factor but not the only factor. Intermittency is a factor. Geographic limitation is a factor. Land consumption is a factor.

Cheap intermittent energy is an okay supplement, but cannot reliably deliver when it is needed. Hydroelectric and geothermal are great, non-intermittent clean energy but are impossible to build without the right geography. Fossil fuels are cheap, and deliver power anywhere but emit carbon. Nuclear power isn't as cheap as fossil fuels or intermittent sources. But it's the cheapest non-intermittent source that isn't geographically dependent.

If our goal is to fully replace fossil fuels, then nuclear is the best option (besides building geothermal and hydro where we can). Sure, solar thermal can deliver clean energy without the need for additional energy storage. But we could build twice as much capacity with nuclear and use a fraction of the land, and avoid having to build larger plants in the north and south, and avoid seasonal output fluctuations.
Copyright infringement doesn't change whether you charge for the copies or not. No authorization === infringement. Fair use privileges never let you reproduce and distribute an entire work for casual consumption.
The WebKit team just approaches things from a different angle than the Chrome team does. Google/Chrome jump on the new shiny features bandwagon right away to keep the favor of web devs where the WebKit team waits until they know they can implement new features in a way that doesn’t balloon resource consumption and prioritizes end users over developers.

There’s little need for most web apps to be riding up against the edge of standards anyway because 9 times out of 10 they’re bog standard CRUD apps that’ve been trivial to build since the heyday of Ruby on Rails.
I haven't had a twitter account for years (and in fact block all twitter domains on my home network). I fail to see any upside of it especially when something like this happens. There seems to be potential backlash for posting anything these days; are there any downsides for not posting or having an account to show off who I "follow"? Is my e-cred lacking because of it?
Norman Myers Dies at 85; Sounded Early Alarm on Environment
> Apple doesn't give a toss if your app is cross platform.

Maybe but they sure as hell don't make it easy for cross-platform software to target their platforms. As far as I'm concerned, the only feasible way to target Apple platforms at this point is to:

1. Buy a Mac so you can officially run macOS and Xcode.

2. Spend $99 every year for an Apple developer license.

3. Spend the time to learn Swift, a language which despite being touted by Apple fanboys as being cross-platform is basically useless unless you're targeting the official Apple APIs.

4. Learn and stay up-to-date with Apple's ever-changing APIs (just wait until Cocoa and Cocoa Touch are completely deprecated in favor of some other API that is only accessible via SwiftUI... calling it now)

5. Keep up with Apple's ever-changing policies around what and what is not acceptable within their walled garden.

6. Give 30% of your profits to Apple.

Fuck that shit. Look, I don't use Electron applications as a general rule and I do agree with your gripes about "web based cruft". But at least it's possible for developers to learn that cruft and use their knowledge to write software without spending a ton of money and having everything they know be limited to Apple's walled garden. As much as Hacker News loves to hate on JavaScript, guess what? It's free and accessible. Anyone in the world can learn to use web based technologies to build software and enrich themselves (and maybe even others). If you're writing software for Apple platforms, you're only working to enrich Apple's ecosystem and investing your own time and money to do so. Maybe it's just my Linux / FOSS fanaticism but this perspective toward software development just doesn't resonate with me. I want anyone who wants to use the software I write to be able to use it, not just Apple's customers.
I should have clarified that I don't think FK's are bad ... just that if you are going to use them you need to plan for that.

Like you, I have been bitten by this in many different environments on both sides of the fence. In certain environments the absence of FK's has caused major headache and likewise in other environments the presense of them and the lack of a robust db design has meant the FK's cause more harm than good.
California has quite a few composting landfills. So GP is calling for the same technology that's already used in parts of California, perhaps covering more people than the entire population of Norway (5.4 million people)

Map of composting facilities in California: https://www.biocycle.net/2018/03/12/california-composting/
Nobody was talking about Tesla Powerwall. We're talking grid scale energy production and storage, not at the level of individual houses. You can't remotely compare a nuclear reactor to a house-level battery setup.
> discouraging cross platform software

That is a patently ridiculous statement.

Apple would obviously prefer you write apps for its platform only, but as long as you don’t _defect_ to another platform, why would Apple care whether an app you use on its platforms is written in one language or another? If an app you want to use is available for its OS, it makes you that much more likely to start/continue using Apple products.

If it’s written in JavaScript, Swift, Python, or COBOL is irrelevant; what’s important is (a) that the software runs on macOS or iOS, and (b) that you don’t get a better experience elsewhere using the same app—because that _will_ likely lead to a user switching away from Apple’s products.
I had a job where the database was intentionally lacking FKs so that users could input data out of order, for example create a shipping route Foo that goes to a warehouse Bar, before the warehouse existed. Let's just say it was a suboptimal design.
Who doesn't think climate change is happening? Even the hardest skeptic acknowledges natural longer term climate change. Others acknowledge recent history as shown in these graphs but doubt the causation. Causation is very difficult to prove without a controlled experiment, so that's a reasonable doubt. Others accept the causation but doubt the predicted future changes, which absolutely are not settled, so they're right to doubt. Others accept predictions but doubt the cost to society will be great enough to warrant some expensive measures proposed to reduce it. That's absolutely not settled either.
True enough, one could name any year between 1979 and 1985 as the "invention" year of C++, and the claim would have some merit. http://www.cplusplus.com/info/history/
I guess what I'm saying is that inevitably in these sorts of discussions, about legal repercussions, the assumption is that the torrenters are physically located in the US 50 states.
We had an "interesting" bug where we inadvertently ended up polling postgres advisory locks around 6 million times per minute from a cluster of 200 servers. It added about 20% load to the database, enough to be anomalous but not enough to outright trip any alarms. The overall database performance was fine.
Some lessons in life you only need to learn once.
The "criticism" as it pertains to CockroachDB and off-the-shelf 2PC is less so about 2PC in isolation and more so about layering 2PC on top of consensus groups used to persist records. When any given txn does the "prepare" phase, it lays down markers for a possible upcoming commit. If the 2PC coordinator fails in an inopportune moment, there's a delay between the failure and the markers being cleaned up (whether or not the transaction is "reprocessed" or aborted). The reason why this delay is problematic is because any subsequent transactions that happen upon said markers, they just have to wait for the resolution ("commit"/"aborted") aka it blocks. So clearly recovery must be built into 2PC, i.e. the transaction state itself must be persisted. This is done so in the same way the markers/regular writes are, through consensus. But marking the transaction state as "committed" can only happen once we're guaranteed that all the individual write markers are persisted. Which adds a second round of consensus.
Have you used openbsd for anything lately? Systemd is better than the horrible mess of upstart/sysv etc, although the one linux laptop I run is using void (and thus, runit) and you can type init 6 and it doesn’t randomly hang for 2 minutes while shutting down if you’re not using gnome/kde.. imagine! The future is here ;)
> That's fine when one application is using the database.

It's not even fine for a single application. Said application has bugs in it. Said application can (and will) crash in unexpected ways that leave the database in an invalid state. And if you think that "oh, that will never happen to me". You just haven't been around long enough. It will happen, every single time. Any system without foreign keys will have corrupt data in it. Said system will have user-visible issues as a result.

Just like only the backend can truly validate user input from a webform, only the database can validate its input.
I fail to understand why people think ridding ourselves of the status quo isn't going to result in alot of collateral damage.
It's confusion over the terminology. There are two definitions of "foreign key" in wide use:

(1) When one table's key occurs as a value in another table, in that second table that column is sometimes called a foreign key. For example, table A has id, table B has A_id, and people refer to A_id as "a foreign key".

(2) When you define this relationship explicitly in the database, so that the database can enforce it (and/or to document it), that's called a "foreign key constraint" but also sometimes just a "foreign key".

This article just means they don't use #2. It doesn't mean they don't use #1.

The phrasing was probably clearer in the context of the discussion they were having at the time because the comment above it linked some docs for the software in question (qh-ost), and under the "Limitations" section, those docs said, "Foreign key constraints are not supported." So to them it was clear they were talking about database constraints.
> FKs are a performance impact. The fact they require indexes is likely fine, since those indexes are needed anyhow. But the lookup made for each insert/delete is an overhead.

You have to check referential integrity somewhere. You can do it in the application or you can let the RDBMS do it for you, but it will have to happen somewhere. So the overhead argument is kind of bullshit. Yes, managing the integrity in the app might provide more flexibility, but it comes with a price of, well, having to do your own integrity checking and introducing more bug space into your code.

> FKs don't work well with online schema migrations.
...
> Doing schema migration of P is just not going to work. Recall that gh-ost renames the table at the end.

So basically, the problem is not foreign keys, the problem is gh-ost implementation. Since they don't use FKs, they implemented their migrations in such a way as to make it impossible to support foreign keys.

Yes, in the parent-child example, to migrate the parent you would have to migrate the child. But it is not an impossible thing to do. Create the new parent, import the data, map the record ids from the old parent to the new parent, create new child, drop the foreign key, import the data, update the FK field using the map and create a new FK. Rename the tables and you are done.

> When eventually you want to shard or extract data out, you need to change & test the app to an unknown extent.

Sharding your data is not something you do on a whim. And you will need to test your app. But you were going to test your app anyway, weren't you? Or did you think that you could split your database into multiple databases without any testing? As for unknown extent, that is kinda bullshit. Look for places that catch integrity exceptions. Thats what you need to look at. Look at your database schema and if any of your tables are "ON CASCADE DELETE", go and punch your DBA in the face. If you are the DBA you might want to start running before someone else finds out.
The commenter would do well to RTFA before slinging complaints that have already been addressed in the article.

The article is cool-headed and factual, so don't get hung up on the repo name.
> CQRS is one of the biggest examples I've seen personally for this: your flexibility will go down, work to do "basic" things will go up

The only time I've worked on a codebase that had implemented CQRS, it was when I was given to maintain a crud application to manage maybe 20 different records. Rarely used. The people who had developed it in .net mvc were of such technical prowess that, besides the CQRS pattern, the frontend still had a functional shopping cart (yes, you clicked on "save" and your "order" went to the shopping cart, relic of the mvc demo app).

Sometimes I wonder if I've just been unlucky or the world is all like this.
Wow, remember the walk to the train station after school one day where myself, and several other nerds would stop by the local computer shop and drool over what we’d be asking for on our birthdays or upcoming christmases.. I remember the day the Spectravideo turned up.. It was #1 in my mind for quite some time.. Obviously something big and better happened, but by golly, that is one of those few I must have moments.. I did get one, some 20 years later }:-8)
Report: Chinese Government Assigning Han Men to Live and Sleep with Uighur Women
Quantum Machine Learning Hackathon
It's a composite of LORRI images, which is panchromatic. That means it doesn't have any filters in between, and it measures the intensity of light across all visible wavelengths (and probably a bit of near IR -- so panchromatic), that's why it's grayscale -- it's measuring the intensity of light.

I've downloaded all the mission LORRI and MVIC raw files, and I know "by eye" that MVIC isn't near as good resolution as LORRI.

Edit: after checking the linked file, then yes, this version must be an upscaled MVIC image (I saw an almost 7k by 3k image and immediately thought of LORRI). Yet, there are same views from the LORRI instrument, which are far more detailed.
React has been around for 6 years and seems to be getting better and more common, not less at the moment. I can't see a huge reason to switch on the horizon, wheras in the previous iterations of knockout.js, angular and ember there were some pretty clear things that were big pain points for me. In the 2009-2013 timeframe I think thats where the framework meme started - I can't say its nearly as accurate in 2019.
I don't think they are even hiding their motivation. It's basically why Chrome exists, as well: Google needs the open web to stay competitive with native apps, because they only earn money on the web.

There isn't really anything nefarious about that, and at the moment it has the benefit of aligning Google's incentives neatly with users'.
A Man Launched a New Internet Service Provider from His Garage
An important point is that renewable energy and battery storage continue getting significantly cheaper with every passing year, whereas nuclear power is not getting any cheaper. That's why I said we're at the inflection point. It's not accurate to just take today's figures and project them forward; anticipated gains need to be factored in too. That's why nobody's building new nuclear; even if we assume your numbers are correct and say it's slightly cheaper now, it won't be in a few years. Nuclear power plants need to run for decades to recoup their large capital construction costs.
> prevents

This word is not present in the post you replied to. I said more difficult - and forbidding some cross-platform libraries certainly has that effect.
I have great idea. Since poor people can't pay very much in taxes, how about we have required government work programs to make up the difference? IE: you won't get paid, you will work your tax bill off in the form of labor..during your free time and on weekends.

Many countries have tried taxing net worth. The result is always the same: billionaires leave the country and investors think twice about building a business there...which means less jobs and a worse-off economy for the rest of us.

The government just isn't good at innovating and will waste that money on 'administrative costs'.

The funny thing is that the rich already pay the majority of federal taxes in the US. This isn't including all of the people they employ that are also contributing taxes to the government till.

It never seems to be enough because all of that money is pissed away and nobody is ever held accountable.
You failed to address literally all the things I pointed out.

> The problem is 9 times out of ten not the government. Here's a better idea: let's make censorship impossible in all forms.

PayPal and Visa only make money when they process payments. Not processing payments means they don't make money. Not processing payments for Snowden is therefore likely outside pressure from the government. Not processing "immoral" transactions is likely outside pressure from investors or advertisers, or heck, probably their risk management team.

PayPal is a private company and can choose not to process payments for anyone, for any reason. The Fed/ACH doesn't have the same issues because they are a service in the public interest. They will process payments for anything legal for 1/10th of a cent each over the span of a couple of business days. By the end of the year, instantly, via RTP.

> The ACLU is currently suing New York state for financially censoring an organization which likewise committed no crime.

Luckily being a public institution remediation exists through the courts. BTC's irreversibility makes remediation impossible. You're pointing to a big feature as though it's a bug. Just ask the victims of the ransomware.

> Addendum: Not to mention the millions of people who live in censored countries (Iran, Venezuela, etc) who are totally innocent. Or the billions of people worldwide who are cut off from western monetary institutions in the name of anti-money laundering laws - people censored purely because they were born in the wrong country.

Take it up with your government. That's how government works. You don't like it, change it, don't circumvent it. It's like setting up your own parallel government because you don't like who's in power: that's not how it works. Do I agree with sanctions policy? Lord no. However, I can always lobby to change it. I think you'll find the majority do agree with sanctions policy and that you're undermining democracy.

> Or how about the billions of people who live under authoritarian governments which outright censor them. Are they expected to lobby their masters to achieve political change?

No, they're expected to overturn the government. Freedom isn't free, and all that. The censorship of their transactions is literally the least of their problems. Social problems require social solutions. Or phrased glibly: bitcoin won't help you as you mine minerals in the gulag. It won't help you avoid the gulag and it sure won't do anything to help you once you get there.

In fact, I'd be more worried about transacting on the indelible public (pseudonymous) blockchain than transacting in say, cash, if I didn't want the government to know what I was doing. You don't think the PRC would build automatic deanonymization tooling?
Storing data in text files is the biggest con pointed at proc. Store data in binary, so that its easier to read by everything.
But, if you want to ensure the data is never visible in an inconsistent state, you either need to use db-level concurrency-related features like transactions or locks; or some kind of lock or other concurrency-control features at the app level while guaranteeing the db has no clients other than your app.

It seems difficult to wind up with better performance characteristics by doing this than using the higher-level abstractions the database is already supplying for this purpose, like constraints. I suppose it's possible with enough hours by enough experts, as you suggest. I doubt that's what github actually did though, they probably instead decided to write app logic that was resilient to visible data inconsistency. Which sounds difficult and dangerous to me, but github is a pretty reliable app, so I guess something worked.
I don't think it's just the "rules" for a Chinese audience (though that doesn't help); I think it's the economics of making movies primarily for a global audience, rather than a particular language, culture, or even sub-culture. This was an "aha" moment in realizing why so many movies over the last decade contain seemingly lazy, blunt dialogue, lacking subtlety or subtext: the meaning needs to come across clearly in subtitles and dubs, divorced from English idioms, cultural context, and intonation.
Anyone want a docker compose file?

Would take about 30 minutes to actually get everything up if you have most of an idea of what to do and a sloppily written guide.
FYI, you might want to check out ZomboDB[0], which integrates Postgres and ElasticSearch. It's open source[1] and, fwiw, the developer was helpful when I pinged him with some questions a while back (and is available for consulting services).

From the project's github page[1]:

ZomboDB brings powerful text-search and analytics features to Postgres by using Elasticsearch as an index type. Its comprehensive query language and SQL functions enable new and creative ways to query your relational data.

From a technical perspective, ZomboDB is a 100% native Postgres extension that implements Postgres' Index Access Method API. As a native Postgres index type, ZomboDB allows you to CREATE INDEX ... USING zombodb on your existing Postgres tables. At that point, ZomboDB takes over and fully manages the remote Elasticsearch index and guarantees transactionally-correct text-search query results.

[0] https://www.zombodb.com/

[1] https://github.com/zombodb/zombodb
I think the concern should be on why the electron devs found it appropriate to use a private API, which is against App Store guidelines, risking/preparing rejection for any app using their framework.

The rejection of private keys used, by frameworks, is in no way new (2009 [1]) or misunderstood.

I find it very difficult to understand why Apple is getting any blame/concern for enforcing the violation of a very very old requirement.

[1] 2009, https://stackoverflow.com/questions/1773615/apple-and-privat...

> The reason this has become news recently is the creator of a framework used by several apps used a private API, so when developers who included his framework updated their apps, they were rejected

What’s old is new.
> One of our colleagues just had a baby 2 weeks ago and no one would expect him to attend.

Will he actively be told not to attend? Often this sort of thing is implied to be mandatory.