If I put a camera inside a tumble dryer and the motion causes the camera to trigger and capture a photo, I think I should still own the rights to the image.

The monkey isn't acting with any real understanding of the creative situation so is just an agent of randomness, like the tumble dryer.

Even if the monkey did it consciously, it did it with stolen equipment, on a mission somebody paid good money to go and setup. And of course the photographer set the camera's settings too -- pressing the button is the easiest part.

In fact, lots of nature photographers use "camera traps" with automatic trigger sensor when an animal walks nearby -- which is the same as the "animal pushing the trigger" and nobody seriously suggests those are photos the animals took.

Let say you unintentionally put it in the tumble dryer. Would there be an artistic expression in the picture, or would it merely be functional?

Threshold of originality is a complex gray zone.

> The monkey isn't acting with any real understanding of the creative situation so is just an agent of randomness, like the tumble dryer.

One of the pictures shows the monkey perfectly centered with a friendly smile on his lips. In my opinion a clear indication that he did have an understanding of the creative situation, that he did not just randomly click the button.

I'd love to know what he actually did. You'd think with what is at stake, the lottery would have some serious security measures in place to stop someone doing an obfuscated if(date=x) return [12,34,5,6,7]; or messing with the RNG.

I'm looking at the second example from the image in the article - the blue plane - and can't work out how the algorithm could possibly infer a second wing from that picture.

Presumably the neural network was trained on a dataset where all planes had two wings, so it will predict planes with two wings.

Yeah, there's definitely some previous knowledge of the kinds of objects it's inferring, which is used to deduce the parts.

Look at the chairs' legs, where it's transforming the flat base of the rotating chair into something that looks as wheels, and where it's completely missing the bars connecting the legs in the second tall chair.

Maybe it involves machine learning also and it is able to tell that it's looking at an aeroplane?

It looks like the algorithm expects symmetry.

Given that the word 'software' only really started appearing around 50 years ago [1], that might be a stretch, but nonetheless, I think you do our current set of technologies a disservice.

I'm sure it would be relatively incidental for the majority of HN readers to cobble something together that fulfils this sort of functionality without much work. If your complaint is that languages don't form higher abstractions of things like 'thumbnails', I think that is just due to us collectively preferring the flexibility of lower level code - it's certainly not because it would be difficult to create a language with such abstractions.

[1] https://books.google.com/ngrams/graph?content=software&year_...

I think GP's point was more focused on the threat of allowing a small number of people (or an individual) to do a large amount of harm.

Out of interest, did you only stop drinking caffeine or was it potentially part of a larger set of changes (mindset/dietary/behavioural/etc) made at a similar time?

Nothing changed for me but the caffeine. I did go through about a weeklong withdrawal where I could barely get out of my bed though.. it was tough I did feel I was half dead for a good week, but after that your body adjusts, and dare I say I'm more productive and focused now than when I was on caffeine.

Replace the 'actually' with 'currently'

Why do you think that substitution is a good idea?

Your logic is flawed.

"Some of the times they're not" does not exclude a potential correlation.

For example: "Some of the time, going to the hospital will not make me better, therefore there is no correlation between going to a hospital and getting better"

I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a smaller but different CSS file for each page you visit.

My impression is that number of requests is a more critical optimization than file size (at least when serving CSS sized files)

It's going to depend a lot on the type of site you're building.

Thankfully frontend pipelines like React + Webpack makes it fairly easy to test this out. We spiked out generating individual JS + CSS for each view but ultimately found it wasn't worth it - individual views amounted to very little code with the bulk of the filesize taken up by the common 'core' of our application, and dependencies. We scrapped this specific idea.

What we did end up doing, however, was create a seperate stylesheet just for things required on the very minimal landing page and inject that straight into the <head>, which gave us significant speed improvements.

Just to clarify (after I've re-read my comment) - we didnt explicitly create a landing page stylesheet, instead we were able to use Webpack to automatically create a seperate stylesheet at build time containing just the styles used in the dependency tree of the landing page.

Webpack is super handy like that - no need to be aware of this and manually keep track of a seperate stylesheet :)

Really depends. How big is the once CSS file you're loading and how much of the CSS is common from page to page? If 20kb is for a specific component on one or two, less-visited pages, then it probably doesn't make sense to lump everything together.

A fairly safe default starting point would be:

1. Tiny subset of inlined critical CSS (See https://www.smashingmagazine.com/2015/08/understanding-criti...) 2. Asynchronous + rel=preload loading of the main CSS of your site 3. Then, if there are hefty chunks of CSS for specific pages only, bring those in on those pages.

This changes a bit if you're using HTTP/2. Then the multiplexing makes it beneficial to break the CSS into a few smaller files instead of one big one.

In the end, you probably just have to experiment and test. :) No guaranteed "this is best" approach here.

From what I've heard, the answer depends greatly on whether we're talking http 1 or 2

HTTP/2 is pretty much everywhere now, including virtually all mobile devices. So targeting HTTP2 is pretty sensible IMO.

Serving the page with inlined CSS also has the compression benefit of many html ids and classes being repeated in the CSS.