Even Google can not buy more old Intel Macs or Pixel 6s or Samsung S20s to increase their testing on those devices (as an example)
Maybe that affects less devs who don't need to test on actual hardware but plenty of apps do. Pretty much anything that touches a GPU driver for example like a game.
If we're talking about pixel perfect rendering there are various issues in the Web APIs that conspire against you.
devicePixelRatio (dpr) - This is supposed to tell you how many CSS pixels = one device pixel. This particular demo ignores it. On my Windows PC my dpr is 1.25 and the site looks horrendous with every other pixel 4th pixel of a font being double wide (or something along those lines). Not dissing the demo, it's cool. It's uncommon for Web devs to be aware of these issues as like 99.99% are on a Mac and never set zoom to anything other then 100%
The idea was supposed to be, you could take the CSS size and multiply by devicePixelRatio to get the display size. Unfortunately that does not work for various reasons.
There's zoom. Firefox and Chrome change the devicePixelRatio in response to zooming. Safari does not. Even if Safari supported this it's not enough. You can maybe repo how bad the site looks on my Windows PC on a Mac by zooming in on any browser (pick zoom from the menus, not pinch to zoom - see below)
Next there is pixel snapping. The short version is, imagine your window is 3 pixels wide and you ask the browser to make 2 elements side by side each 50% wide. If you check the CSS width both elements will say they are 1.5 pixels wide (getContentBoundingRect().width). But the browser won't display a 1.5 pixel element. I will snap one element 2 pixels and the other 1 pixel. To find out which is which you're supposed to use ResizeObserver with devicePixelContentBoxSize, but again Safari doesn't support this. It's not just with splits, that just the easiest way to demo the issue. Get this wrong and your checkerboard background will have a stripe somewhere where the checkerboard is missing a row or column.
Next there is pinch to zoom. It's separate and reported no where in the Web API AFAICT. The browsers will re-render text/svg to a higher resolution when you pinch to zoom but they don't pass that info to the page so it can not re-render canvases in response.
So: tl;dr, you can't - partly because of Safari. Partly because the Web is missing functionality
I should clarify I'm indeed not using the api call to get device pixel ratio; I forgot I had ended up not needing it because all that code is stuff I wrote about a year ago, lol
Sounds like you found your next promotion at Apple. They can change anything. "I like Pepsi" -> "I like Coke" -> "I recommend Company A" -> "I recommend Company B". etc... "I'm voting for Candidate C" -> "I'm voting for Candidate D"
You can market it is helping people with strong accents to be able make calls and be less likely to be misunderstood. It just happens to "fix" your grammar as well.
Just as a note to 100 thanks < 1 savage attack. I run several open source sites that collectively get 240k unique vistors per day. They've been running for > 10 years. I get less than 2 thanks a year. I'm not saying I deserve any or that I want them. Only providing data.
I also have 100+ open source projects on github. A few with ~1000 stars. Same thing, few if any thanks.
I wish there was some way to make it easier to thank. I'm just as guilty of not thanking all the open source projects I use except for the few I donate to.
It would still suck to get attacked but it would be motivating to get thanked as well.
Just wanted to say that each of those stars is a small thank you from someone. At least I always gave them with this in mind, and I always assumed others did too.
I don't know which projects are yours, but a big thank you to you and everyone else who is helping others either through opensource or otherwise!
hackers effectively killed https://glslsandbox.com It's been closed for about a year and a half because some hackers spammed it and no one has time to deal with it. There are other sites like shadertoy that do something similar but still, it sucks to see someone's project get shit on by assholes.
As for denial of service issues, because it's free I've mostly hidden behind cloudflare in the hope of not having to personally deal with those kinds of issues on my own stuff.
It's always annoying to me the hacker attitude of "it's your fault if I can break your stuff. You should have implemented it better". Well, I can break your windows, your door, your body and it wouldn't be an excuse that it's your fault because it's possible. Still, I know it's impossible to get rid of the assholes so ...
Physical systems are different from information systems. You can make an impenetrable information system, but not an impenetrable physical system. Physical systems are inherently safe due to their locality, and can benefit from security-by-obscurity.
When you hook up a weak information system to a global network where anyone can interact with it, and someone finds a way to break it, perhaps it is worth looking into the systemic weaknesses instead of getting angry about a given attacker.
I’m a big guy, 6’3’’ 260, multiple Ironman, sport, climbing, lifting and hunting brush with a bit of combat training over the years. Most people in my life I imagine I could kill with my bare hands. But I don’t, because like you said that isn’t how life works.
Yet people apply it to anything they want recklessly. Cars, phones, or like above peoples projects. I wonder how they would feel if I beat the shit out of them and laughed, telling them their mom should have fucked someone bigger.
I'm about your size, and have actually done what you describe (not by my own choice). The process takes much longer than one might suppose, however incredibly difficult to imagine.
We are nothing more than temporary meatbags, fragilely broken. Take care of yourself, each other.
Sometimes, other people can decide to put you in a situation where among all possible actions, physically stopping that person by any means is the least bad option by several orders of magnitude.
People refer to this as having "no choice", assuming most people understand "standing there and watching them repeatedly stab my infant with a fork" is not a choice anyone would make. It's an idiom.
>Most people in my life I imagine I could kill with my bare hands. But I don’t, because like you said that isn’t how life works.
You don't, not because you are such a great guy, but because society's protection of physical systems is rigorous through thousands (millions?) of years of evolution. If you assault someone in the modern day, you will probably get thrown in jail or you will get shot.
Our information systems (such as the internet) are systemically weak. They are poorly designed and have not gone through the same evolution. I think it is good to exploit these weak information systems so that they can evolve.
If there were no laws, then there would be no evolutionary pressure to pacify the ghenghis khans of the world. And it's not so much the rules on paper, but the organization of power that enforces the rules.
It's not weird it's just uncomfortable for you to grapple with directly, that discomfort being a product of the same evolutionary pressure.
What I'm saying doesn't oppose what they're saying. That poster was just boasting about his ability to kill others, re-framed in a way to suit slave morality and make himself look like a "good" person.
Arguably the best transportation system in the world is in Japan. It's made from ~100 private and mostly private companies. For some reason, tax and spenders never seem to understand that.
Set up the incentives right as demonstrated it can work. Coversely, public transporation will always have funding issues because there is no way to setup the insentives.
Not really. The Japanese public transportation system is analogous to employer sponsored healthcare in the US. The employers and employees get significant tax incentives to get employee commuter passes.
Ths US tax system makes capital intensive business difficult to operate in the private market. It’s one of the larger distorting influences in our economy. Most public transit is operated by authorities, which are public corporations with their own books and tax exempt bonding authority.
Based on your saying “tax and spend”, I assume you identify as a modern conservative. The tax and spend aspect is really the road system - one of the ways that Nixon tried to prop up the flailing economy was to invest billions into highway aid and projects. Roads = lots of oneshot construction jobs and local patronage.
Rural, exurban and suburban towns didn’t have broad paved highways until those programs took off, as states didn’t have the will or the dollars to fund them. Drive around upstate New York and you’ll see lots of “old state route XX” — all of those roads were built in the last 50 years, all paid for by external federal dollars. (And narrower than the ridiculous wide streets in subdivisions today)
Is really. The majority of systems, especially the larger ones, get no subsidies. Mostly the smaller rural ones get subsidies.
> I assume you identify as a modern conservative
you'd be wrong.
But I still bristle every time someone says we need public transporation when my favorite system I've used for decades is not public and is designed to be positive feedback loop. No public system can do that AFAICT because there's no way to set up the incentives. It's just an expense with indirect benefits, to easy to cut funding on and make it just a "for poor people who can't afford a car" system
It is not a schizophrenic zip file to have inline headers that are not referenced in the TOC. the TOC is the only source of truth in a zip file. It was designed this way in purpose so that you can add new versions of files on your 20 disk zip without having to re-write all 20 disks. Pkzip would read the TOC from disk 20, append your new file to disk 20 (or 21 if there was not enough space) and then write a new TOC at the end that does not reference the old file still in the zip. That is by design. Reading anything other than the files in the TOC is an invalid zip reader
While that is true (even if some people really want to stream read zips and will thus trigger tar-style conflicts) that is not what the article is about. The article is really more about software using the "size of central directory" field to find the central directory (a sin Python's standard library apparently commits) versus the "offset of central directory".
A commenter on an other post of that article noted that technically there's no reason for the central directory to be right before the EOCD so seeking backwards from the EOCD by the size of CD is just incorrect. In fact zip was designed such that the central directory could be split across multiple disks (and later files), so it was not possible to guarantee a simple backwards jump from the EOCD to the start of CD.
> technically there's no reason for the central directory to be right before the EOCD so seeking backwards from the EOCD by the size of CD is just incorrect
Yes, and in fact APPNOTE.TXT expects implementations to deal with discontiguous CD/EOCD records; it actually mandates that some records appear between them. (It's where ZIP64-specific records go, for example.)
The whole thing seems to stem from a belief by the author of this post that Info-ZIP is the canonical implementation. (This is of course wrong. That would be PKZIP.)
If Info-ZIP is exhibiting the behavior described, then the Info-ZIP implementation is flat out wrong.
(This has happened before. See <https://news.ycombinator.com/item?id=27925393> where the author of that post provides pushback to Mark Adler, receives pushback from Adler in response, and then just stops pushing and defers to Adler's reading. Adler is an expert in his domain, and he's made valuable contributions to free software, but his expertise is in compression, and he's not the authority on the spec or the format; Adler didn't create ZIP or write APPNOTE.TXT—Phil Katz did.)
> a belief by the author of this post that Info-ZIP is the canonical implementation
↑ Where did you get this from?
I don't think nowadays there's such a thing as a canonical implementation — ZIP implementation world is too fragmented and implementations are too widespread.
One more note is that the article isn't about who's right or wrong in terms of interpreting APPNOTE.TXT — this is besides the point. The point there is that a parser discrepancy can cause security issues, and the article documents just another discrepancy found in the real world implementations (and there are A LOT of these with regards to the ZIP format).
> this makes sense—technically both the offset of the Central Directory and the size of the Central Directory are redundant when you consider that the End of Central Directory Record should be, well, at the end of the Central Directory. In a proper ZIP file the following equation should be true: (position_of_EoCDR - size_of_CD == offset_of_CD)
This is a pretty clear statement on normativity.
You also left out an important part of my comment when you quoted it. (The operative word at the front of the sentence is "seems".)
> This is a pretty clear statement on normativity.
I disagree – it's a technical remark on redundancy of fields (this is related to my hypothesis in the article that redundancy in formats is the primary cause of parser discrepancy). It doesn't acknowledge InfoZIP being canonical in any way.
> You also left out an important part of my comment when you quoted it. (The operative word at the front of the sentence is "seems".)
It's talking about how the EOCD contains both the size of the central directory and the offset of the start of the central directory, which is redundant. So we end up with some tools honoring the offset, while some subtract the size from the EOCD.
It's true that the other comment is unrelated to the content of the article, but it's not true that the offset and size in the EOCD are redundant (for the reasons given in the earlier sibling comment).
I can think they would test which parser you have using some social engineering and create the zip appropriately, but they would also need to know the accountings parser. So I think they would just do the first step and leave it up to chance.
The interaction that messes me up all the time is the side button and payment related stuff
One press turns on/off the display
Two taps enables Apple Pay
Quite often my timing is not perfect or one press isn’t hard enough so I shut off the display
Then, paying with Apple Pay is a double press but paying for transit is no press. but often I’m absent minded and as I’m walking through the transit gate my brain thinks “must pay” “pay = double press” so I subconsciously double press and the gate screams since is not in transit mode now it’s in Apple Pay mode
Maybe that affects less devs who don't need to test on actual hardware but plenty of apps do. Pretty much anything that touches a GPU driver for example like a game.
reply