j4_james

Interestingly the text is garbled after it's loaded. So if you view the page with JavaScript disabled, the original text is completely readable (no blur effect either). I assume this is an attempt to make the page accessible to robots but not to humans.

This technique may not work if you've got a weird DPI that's causing scaling to something like 150%. In that case you'd need to set your browser's zoom level to 66.666% which is probably not one of the levels it supports. My display scales by 200% so I just needed to zoom out to 50% which has worked on every browser I tried.

Another option is to save the image from the webpage to disk and then open that image in a basic image editor (making sure the editor is not zoomed in at all). I'm not sure how feasible this is if you're on a phone though.

What would have been ideal is if the author of the article had included srcset alternatives for these images to cater for some of the more common high DPI devices. Would then have just work automatically for most people and caused a lot less confusion.

I had the same problem on my laptop which, like many phones, has a high density display. When a website hasn't explicitly provided support for high DPI displays, the browser is forced to scale up the source image (typically by 200%). To see the expected effect, you just need to lower the browser zoom level a couple of times to get the image back down to its native size. You'll know you've got it right when the A block suddenly appears lighter and matches the C block rather than B block (which will now look too dark).

HTML5 does actually support an XHTML serialisation[1] if you need your content to be easily parsed with XML tools.

[1] https://www.w3.org/TR/html5/the-xhtml-syntax.html

The real benefit is not just being able to develop Linux software, but the ability to work on cross-platform code. I do most of my coding and debugging in Visual Studio, but when I want to test the changes on Linux I now simply alt-tab to the bash shell which I have open in the appropriate directory, rebuild the changes with make, and then run the updated executable.

That's not necessarily doable for everyone, but for me that workflow is so much simpler than it would be with dual booting or a separate Linux VM.

This reminds me of my attempt to reproduce the Donkey Kong handheld video game using just HTML and CSS.

http://kong.詹姆斯.com/

I also wrote a short blog post describing some of the mechanics of the build for those that find that sort of thing interesting.

http://www.詹姆斯.com/blog/2016/07/html-kong

I've had an international domain since 2006, and the sad truth is they still aren't widely supported 10 years later (the fuckyeahmarkdown website being a case in point). I don't think people are deliberately filtering out those characters - they just aren't aware that such names are even possible.

In the beginning I used to file bug reports whenever I encountered websites that couldn't handle my domain, but I eventually resigned myself to the fact that most people just don't care. Nowadays I don't even bother trying the unicode most of the time, and just use the punycode version instead.

This is probably not the kind of answer you were looking for, but for me the number one criteria is location. If it's going to take me 2 hours each way to commute to a job, I'm not even considering it. So I find it frustrating how difficult some companies make it for you to find their office location. I really wish the Hacker News "Who is Hiring" threads had zipcode/postcode as a required field.

And for something like a job board, being able to register my location and have it display approximate commute times for each job listing would be a dream come true.

> If they released streaming alongside movie theater releases I would imagine you'd knock out 90%+ of the piracy out there.

That's the problem that Sean Parker is hoping to address with his proposed streaming service[1]. At $50 a movie, that doesn't seem unreasonably priced. Until then, though, there's always the Prima Cinema option[2], but then you're looking at $500 a movie, plus $100k+ for the the initial setup, so it's not a great choice if you're impoverished.

[1] http://www.businessinsider.com/sean-parker-streaming-rental-... [2] http://www.businessinsider.com/prima-movie-2016-4

That's disappointing, because CSS wouldn't be a viable replacement in this case - it can't animate XML attributes like seed. Or is that something they plan to support one day?

I was curious if this could be achieved without the need for JavaScript, and I see there is an SVG animate element that looks like it ought to do the trick. In theory you should be able to get the turbulence seed to cycle from 0 to 500 by adding an animate child on the feTurbulence element like this:

  <feTurbulence id="turb" baseFrequency="0.2" type="turbulence">
    <animate attributeType="XML" attributeName="seed" from="0" to="500" dur="50s" repeatCount="indefinite"/>
  </feTurbulence>

It's not quite the same as the JavaScript implementation, which makes the seed random, but I wouldn't have thought that was necessary in this scenario.

Anyway, while it seems to work OK for me in Firefox, it doesn't look quite right in Chrome, and it fails completely in IE and Edge. Not sure if I'm doing it wrong, or SVG animation is just not well supported yet, but this would be my preferred solution if it could be made to work reliably.

On IE and Edge, every sentence becomes prefixed with the string "null". This appears to be caused by the code that clears the element content with:

  el.innerHTML = null;

Changing that to a blank string fixes the issue for me, i.e.

  el.innerHTML = "";

LLD is really three different linkers combined. You specify which type you want with the "flavor" command line option [1], but there are also versions of the linker with the flavor hard-coded (these vary depending on the platform).

My understanding is that the darwin flavor uses the atom-based architecture, while the gnu and windows/link flavors use a section-based architecture. There was a thread on the llvm-dev mailing list that explains this in more detail. [2]

I don't know much about the linker script side of things, but I was under the impression that they were working on that.

[1] http://lld.llvm.org/Driver.html [2] http://lists.llvm.org/pipermail/llvm-dev/2015-May/085088.htm...

According to Wikipedia it's Google, Facebook, Amazon and Apple [1]. But I have also seen Microsoft substituted for Apple in other references.

[1] https://en.wikipedia.org/wiki/Big_Four

Would this not still be vulnerable to a kind of man-in-the-middle attack though? I don't know much about the workings of bluetooth, so maybe this just isn't possible, but I was envisioning a kind of relay device that could capture an incoming signal, forward it to another device, from which it would then be rebroadcast.

The idea being you have an attacker standing in front of the door, relaying the bluetooth transmissions to an associate, who in turn rebroadcasts those transmissions to an employee who he has followed out to lunch. That employee's phone then responds exactly as if he were standing in front of the door.

I can't see why this wouldn't work, but I'm sure I must be missing something.

Obviously if the user is forced to confirm an ID request before continuing with the transaction this wouldn't be a problem, but I got the impression from the article that that wasn't necessarily required.

FWIW, you can do content negotiation on the client side with the HTML5 picture element:

http://www.html5rocks.com/en/tutorials/responsive/picture-el...

If a browser doesn't support that, it's probably not going to support the image format you're trying to negotiate anyway. In that case it's just going to fall back to the enclosed default img which is exactly what you'd want.

One of the comments on that twitter thread: "Very glad it’s fixed. Not so great for users of other browsers though. God knows how long they’ll take to correct it."

Except none of the other browsers have that bug. Somehow Chrome is still better though.

Is it really any better for other browsers though? I know I've encountered a fair share of webkit bugs that have been confirmed yet still left unresolved for years on end. And they also aren't above closing bugs as wontfix that clearly are genuine problems.

Obviously that's anecdotal, but I'd be curious to see someone do an analysis of turnaround times on the public bug trackers. It may not be feasible to detect incorrectly closed bugs, but a measure of the time taken to resolve confirmed bugs could be an interesting statistic.

His previous hack relied on browsers rounding the result of an opacity calculation in order to force a binary outcome (i.e. one of two colours rather than multiple shades). Once they improved the accuracy of those calculations this trick was no longer applicable

I'm probably not explaining it very well, but you can read the full details of the hack here: http://lcamtuf.coredump.cx/css_calc/

It's a configurable option in Firefox, and on Windows at least it defaults to navigating backwards.

http://kb.mozillazine.org/Browser.backspace_action

That's good to know - I think that's a sensible move, and I agree with those that think Apple's change is a bit silly. However, my point still stands that emoji have always been a source of miscommunication [1] and will continue to be so, with or without this change.

[1] http://www.dailydot.com/debug/emoji-miscommunicate/

I'm not sure this is that big a deal considering the default Windows representation of the pistol emoji has always been a toy gun rather than a realistic depiction of a firearm. It looks more like a ray-gun to me rather than a water pistol, so you're unlikely to say "we should [ray-gun] John after school", but there's clearly opportunity for misinterpretation if you're trying to communicate with these symbols.

But I would have thought the obvious solution was to avoid using emoji as a form of communication. They're always going to vary from one platform to the next, so you never really know exactly what the recipient is going to see.

> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements.

I think the distinction here is that the one is an identifier which is not intended to be dereferencable, and the other is a link to a resource which has to be retrievable. In the good old days the id would most likely have been a URN and the link a URL, but that distinction was being discouraged in favour of the more general URI term at the time the Atom spec was developed. [1]

So while they're syntactically both URIs (well technically IRIs), they're functionally quite different. It may be debatable whether that's a good enough reason for the one to be an element value and the other an attribute value, but I don't think that decision was obviously wrong.

[1] https://tools.ietf.org/html/rfc3986#section-1.1.3

It may interest you to know that some older programming languages didn't originally support recursion, although they did support function calls (early FORTRAN being one example). The return address for a function call was typically stored in a fixed location associated with the target. So if you called that function once, you wouldn't be able to call it a second time until the first call had returned, otherwise you'd end up overwriting the first return address.

Not that I think that is the OP's problem - just a bit of interesting history. Support for recursion may seem obvious in hindsight, but there was a time where that wasn't the case.

That looks like your browser is somehow misinterpreting the character set of the page. What you're seeing appears to be something like code page 437 (https://en.wikipedia.org/wiki/Code_page_437) rather than unicode.

What browser/os are you using? Is it possible you're going through a proxy that is altering the HTTP headers?

Yeah, the parent comment was oversimplifying things. That particular solution only works for values of n != 3λ+1 (λ = 0,1,2,...). If you read the paper, they provide a number of different constructions, each one covering a different subset of n.

For n=4, I believe you'd need to use construction B, which is (k, 1+((2(k-1)+n-1) % 2n)) and (2n+1-k, 2n-((2(k-1)+n-1) % 2n)). Your resulting coordinates then become:

  (1,4) (2,6) (3,8) (4,2)
  (8,5) (7,3) (6,1) (5,7)

I think that should be a valid solution.

FWIW, it works for me in Firefox on Windows 10. Click and drag with the mouse, clicking on the arrows, or swiping on a touchscreen all work fine.

As others have mentioned, most of these don't work on Firefox. For the few that I looked at, the only problem seemed to be a missing unit identifier on the animation delay. For a zero _length_ the unit is optional, but not for a time type - at least by my reading of the specs. It may work in blink/webkit, but I don't think it's technically valid.

Edit: Have since looked at a few more of the broken ones, and found another problem source being your use of quoted strings for the animation name in some places. That too is not valid according to the specs - they should be unquoted identifiers.

And yet that's very much how object-oriented languages are typically structured.

  object.method()

  "hello world".print()

If you're used to speaking a language like English where the word order is subject-verb-object, you'd probably consider a subject-object-verb language to be "backwards" too. But native speakers of that language certainly wouldn't have a problem.

I'm sure it's just a matter of what you're used to.

Lets say the whole file is 1000 bytes and each of the five chunks is 200 bytes. If 2 and 4 have failed, then the HEAD would return with a Range header like this:

  Range: bytes=0-199,400-599,800-999

The client would then know it had to resend bytes 200-399 and 600-799 (namely parts 2 and 4). If the chunks only partially failed (say 100 bytes of each chunk was received), the HEAD might even return something like this:

  Range: bytes=0-299,400-699,800-999

So now the client knows it only has to resend bytes 300-399 and 700-799 (only the last 100 bytes of chunks 2 and 4).

Technically the Range header isn't valid in an HTTP response (something they are aware of), but conceptually I think the idea works fairly well.