War and Peace was my first introduction to the translation debate as well. I read and loved the Anthony Briggs translation, but I also read a few samples from the Maude translation and didn't think it was much different.
In general, I think there's too much emphasis on language barriers for the layperson. It's the classic problem where passionate people introduce considerations that aren't relevant to the casual user ("Don't use that brand/thing! This brand/thing is 0.1% better!").
I'm fluent in English, but still am capable of missing subtle uses of the language. Yet, we treat foreign (to us) languages as if all of the subtly is obvious to anyone who is fluent in it. I honestly don't think that the average Russian reader is going to see much more in the language than an English person with a good translation. An expert will see it, but not me.
In my opinion the return on investment is much higher for increasing your understanding of both the culture and historical moment, not the language.
Also reminds me of the huge shortcoming that these "simple" serialization libraries have. In most use-cases you're eventually going to need some way to add/remove fields from the payloads.
JSON and protobuf make that easy. You can start emitting the new field and then update the receiving end at your leisure.
With these libraries you have to write your own versioning system. For a small performance improvement over JSON parsing it's pretty much not worth it. There's almost always going to be a piece of lower hanging fruit.
This is a valid concern, but it's possible to work around in a similar way that you do with protobufs: never redefine the format of any message type used in production, but instead, introduce a new message type whenever you need to change the format.
For example, imagine you are sending message type 1 with format "%d %d" and later you realize you actually need three instead of two ints. You introduce message type 2 with format "%d %d %d" and update your readers to support both types. Once those are deployed in production, you update your writers to send the new message.
This is kind of the opposite of what happens with protobufs, where unsupported fields are silently dropped by the receiver, so you can update the sender before the receiver. But this is arguable less safe, since if the receiver drops some fields, it might not interpret it the way the sender intended. In that case, it might be more sane if the receiver outright refuses to process a message it doesn't understand.
I just recently wrote a JavaScript emulator [1] for a simple 8-bit CPU I had built with logic gates. Both were fun projects, but one took a weekend whereas the other took about 4 months. Having skimmed through the author's code, I totally understand why it took them so much longer to get their's working. It's implemented with gate-level simulated logic gates, which is an impressive achievement. It's so much easier to just emulate whole components like I did.
However, don't see any evidence that they have physical prototypes of multi-catom swarms. Seems like they're more interested in the controls side of it, which is itself a very difficult problem.
I imagine physical constraints (such as the amount of power needed to engage the device's electromagnets) would render real constructions impossible. I'd loved to be proved wrong, though.
Like I asked the other person in this thread, what's wrong with that answer?
Not only does it correctly identify the attack vector of this CVE, but I think his advice on how to mitigate it is sound. Is there something I'm missing? The only flaw I see is that it doesn't consider the implications of using PDF.js in Electron.
"If you serve untrusted PDFs in a PDF viewer and you are hosting at your location, it is better be located at different origin than your main app, www.example.org vs pdfviewer.example.org."
My understanding is that this CVE is an XSS attack, so isn't this advice sound? The RCE portion of this CVE is for Election, where every XSS attack is twice as fun.
Is there something about his answer that is wrong that I don't see? I hardly think we can fault someone simply for having faith in the integrity of software that everyone else trusted until now.
Things have gotten so complex that it's difficult to reason about security (even for experts). This is especially true when we're talking about JS code that is running on the client and accepting untrusted input from the global Internet.
Is the origin right? Are all the security headers correctly set? Is it even possible to keep up with all the stuff that is published, today, to sort of try and secure a web app? I don't think so.
My approach is... no JavaScript (script-src 'none'). Just don't do it.
Your approach to sandboxing browser PDF rendering is to just not do it..?
You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application.
I can't see how this would be pragmatic or productive, or maybe it's not meant to be.
> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.
People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things.
I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent.
The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge.
Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
From personal experience browsing websites, especially sites that display catalogues, manuals, or specifications, a whole lot of them produce PDF content and then go out of their way to render it with JavaScript. The worst use horribly performing systems that make consuming the content miserable. Better commercial systems are a step up (Issuu is a whole company that seems to be developed around doing this). Even better ones use PDF.js. But the best ones... drumroll please... just link to the PDF as Content-Disposition: inline. If users want to save it, then they click save. And this is great -- you want your users to have the easiest time possible interacting with your marketing material.
> fill forms in the browser (where their authenticated context resides)
I have never, in my entire life, seen a web form implemented as a PDF where this was anything other than miserable. Use a form, thank you very much. The less SPA magic and the fewer intermediate submit buttons, the better. (Maybe, if the actual goal is for a user to fill out a form and print the result, offer PDF.js to users on Windows who might otherwise be stuck with Acrobat. I distinctly remember Acrobat being the best PDF-form-filling software maybe 20 years ago, but Acrobat has gotten, if anything, worse, and basically every other package out there runs circles around it.)
They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it.
Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
> They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
> Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued.
It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign.
> I'm going to discontinue this conversation though.
Sometimes the PDF itself has to be signed. No conversion from forms. Also, tons of people would rather not have to download the PDF and email it, especially if they are on mobile. There's almost 0 usability advantage to doing that, because Adobe acrobat or whatever other pdf reader that users have and lets them sign stuff is often worse than even a JavaScript implementation. I'd much rather just sign on the browser than send an email back and then... wait or not have an immediate confirmation, or just having to deal with anything else than just pressing next.
I'm sure a lot of people here will disagree but most websites don't target the minority that prefers an email based workflow.
Or they could just implement full support for PDF. It had forms from the get go in the 90's. There is zero need to implement the functionality with JS.
The advice is sound... mostly: there are ways to relax the different-origin nature of subdomains so you'd have to ensure that you're not using them, and some web properties have relaxed SOP by default e.g. cookies, renderer processes, ..., the public suffix list exists to try and mitigate these issues.
Frankly I'd just disable script evaluation if you don't specifically need that.
>Frankly I'd just disable script evaluation if you don't specifically need that.
And how do you know whether you "specifically need that"? As the answer says, it's not for scripting within the pdf itself, it's for optimizing font rendering. For pdfs that you don't control, it's basically impossible to know whether that'd be needed or not. Even for pdfs that you do control, in a large company it's very likely that the team that's configuring pdf.js isn't talking to the team that generates the pdfs, which means you have a similar problem.
Was it an in-service passenger train? A freight train or out-of-service passenger train wouldn't show up.
Sadly, there's very little data available for most trains on US rails. For example, there's no way (AFAIK) to see what freight trains are active on the network. It's a little frustrating in comparison with how rich our air traffic sources are.
If anyone on HN knows of any richer sources for train network data, please let me know. I'm highly interested!
I'm in the middle of it right now. It definitely doesn't suffer from pop-history. I also read Andrew Robert's Churchill biography and thought it was excellent. Not quite to the level of The Last Lion, but that's mainly because it's much shorter.
These lists are almost always useless for comparisons since the definitions between countries vary so widely.
edit: Digging into the sources, the US has 6.4 unsheltered homeless per 10k, but Sweden doesn't even track unsheltered homeless, the most acute category (at 4.5/10k) also contains people in immediate access shelter/hospice.
This is a fair point. To Wikipedia's credit, I think it's adequately addressed in the article I linked.
I think a more general statement could be made. It's nearly useless to make comparisons between countries. The United States cannot adopt Swedish policies and expect to achieve Swedish outcomes. I'd much prefer we discuss policies for our countries in our own contexts rather than introducing comparisons between them.
The parent comment introduced a comparison, though. So, I think it's only fair to introduce some form of statistics.
Thanks for providing a more founded empirical interpretation of the facts! It seems Sweden has some edge on the USA, but the original claim (that it's almost impossible to be homeless in Sweden) still seems as unfounded as I expected.
As another commentator noted, I think climate is something to consider. I expect that you'll find higher concentrations of shelter-less people in more temperate (or at least warm) places. Cultures will evolve to prevent people from needlessly dying, but we aren't inclined to give more than the bare minimum.
> The United States cannot adopt Swedish policies and expect to achieve Swedish outcomes. I'd much prefer we discuss policies for our countries in our own contexts rather than introducing comparisons between them.
And this isn't what anyone seriously proposing for the US to take control of its social issues to do. The mention of other countries usually is just to show it can be done, to be inspired by it and forge your own way to solve social issues.
I don't know why it's usually taken in this absolutist view, where solutions should be implemented as-is because it worked somewhere else. It worked, get inspired by it and figure a way out of the hole in your own local environment...
Yeah, Sweden and the US are different, people are still people and have some overlapping needs, learn how others have done instead of this hubris of "we're different". Everyone is.
I'm not from Sweden but I'd expect homelessness there to be almost never caused purely by financial difficulties or unemployment. The vast majority of homelessness in the Nordic countries is either due to mental health or substance abuse problems, or a combination of financial difficulties and other compounding factors such as those.
GP probably meant it's almost impossible to become homeless in Sweden because of a lack of a social safety net alone.
And one bit of Swedish society that is a bit invisible to the outside: it has an extremely draconian approach to drug abuse. Even though it's a Nordic country and touted for being socially progressive, drug policy here is extremely regressive when compared to Portugal or the Netherlands.
So usually the homeless I see in Stockholm are addicts (alcohol, heroin, amphetamines) that fall through the cracks of the system as they won't stop abusing substances which Swedish policies have no way around to help them, it's extremely punitive for drug use, as even use is a criminal offence. In the case you are taken in custody by the police they may force a drug test and if detected you'll be punished.
This all compounds to leave a marginalised population that has inadequate support to fight their addictions (usually caused by mental health issues) and kept in limbo between the streets and courts to be ordered to get clean.
Yeah that list is meaningless. You won't see homeless camps of homelesd, almost never see a homeless person and if a homeless person doesn't want to be homeless anymore then they suddenly aren't (I know of precisely one exception to this.)
Yeah, don't believe everything you read on the Internet. That list has little to do with actual reality here. You won't see homeless camps of homelesd, almost never see a homeless person and if a homeless person doesn't want to be homeless anymore then they suddenly aren't (I know of precisely one exception to this.)
All that list means is the US vastly under-counts actual homeless people. This is the same well known effect we see in suicide statistics: Sweden just keeps far more accurate statistics.
I agree with CharlesW here. That information box doesn't mention that a normal grid of pixels can also have a non 1-to-1 mapping between physical and logical pixels. Any discussion of pixels that doesn't specifically call out `window.devicePixelRatio` is not going to give people a complete understanding.
This is important. If you're rendering images/graphics with a pixel as your smallest unit then you're not going to look good on most modern devices.
In general, I think there's too much emphasis on language barriers for the layperson. It's the classic problem where passionate people introduce considerations that aren't relevant to the casual user ("Don't use that brand/thing! This brand/thing is 0.1% better!").
I'm fluent in English, but still am capable of missing subtle uses of the language. Yet, we treat foreign (to us) languages as if all of the subtly is obvious to anyone who is fluent in it. I honestly don't think that the average Russian reader is going to see much more in the language than an English person with a good translation. An expert will see it, but not me.
In my opinion the return on investment is much higher for increasing your understanding of both the culture and historical moment, not the language.