An epub is indeed a zip file containing HTML, CSS, font, image, and metadata files.
I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too:
- You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand).
- Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize.
- While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc.
- Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.
Everything's approach has important tradeoffs: the indexing service must be run as administrator/root, and by reading the USN journal it gives users a listing of _all_ files and mtimes on the filesystem regardless of directory permissions. That means that any user who can run a file search can also see every other users' files, which includes their partial web history (since most browsers, including Firefox and Chrome, cache data in files named for the website they're from, and the mtime will often be the last visit time). If you want to avoid this, you can only switch to Everything's traditional directory-traversal-based index, which has the same performance as updatedb/mlocate, Baloo, or fsearch.
I think these tradeoffs are why there hasn't been as much interest in replicating it, combined with the fact that mlocate/fd/find/fsearch are already a lot faster in most circumstances than the default Windows search and good enough for the most common use cases (although there are certainly usecases where they're not).
That's an extremely important tradeoff but it's not an issue in the process: it is possible to split indexing and searching in a root process and querying in a user process that asks the first one, and the first one filters with the different rights. Nothing we've never heard of.
>That means that any user who can run a file search can also see every other users' files, which includes their partial web history (since most browsers, including Firefox and Chrome, cache data in files named for the website they're from, and the mtime will often be the last visit time).
Most people only have a single user. Sharing a computer with someone is not that common of a thing to do anymore.
Here's the colormap I use, which I've made sure never has too-bright colors on the near-white background: https://pastebin.com/raw/AdR3sBSs
Microsoft publish a tool in the Windows Terminal GitHub repo, ColorTool.exe[1], which can turn iTerm2 color scheme files into Windows Terminal ones. That might be your best bet because there are huge repositories of good iTerm2 schemes[2] and really slick tools to quickly make your own with live previews.[3]
It seems madness to give your card to someone to take off somewhere. In Australia they either bring you a terminal to touch at the table (for a fancier place), or you touch the terminal on your way out (for a casual place).
In the US an upscale place would never bring a terminal to your table. They give you a check (receipt), you put card or money down, they take it to their register, and bring back a customer receipt or change.
Money is often a taboo subject in the US, and I think that is bleeding into a slow adoption of touchless transactions in nice restaurants.
It will take at least 5 years for this part of US culture to give way to convenience and security.
*Note I've not spent much time on the west coast; I'm sure they're ahead on this
Debit payments are around 3x as popular as credit payments here and there is, last I heard, a 50-50 split between using cards and phones to make them. There's an interesting demographic association to it as well, credit is much much more popular with older people (50+). Every few months you see a "millennials are killing the credit card industry" fuss.
Not all of them, hardware AV1 has been rolling out over the last year. LG include hardware AV1 decoding in two of their TV lines now (OLED ZX and NanoCell). MediaTek's new SOCs include it, and they're being used in Xiaomi, Nokia, and Motorola phones this year. Amlogic's TV and set-top box SOCs, used in things like the Amazon Fire TV as well as Android smart TVs and dedicated media players, include it. Realtek's TV SOC with hardware AV1 support ships "early 2020."
Hardware AV1 decoding is available on some Android devices right now, and will ship with a lot more over the course of the year. So it seems the perfect time to ship an AV1 option behind an opt-in setting, which is what they've done. If you don't have hardware support and it's not worth the battery drain then you don't have to select it and there's no way they're removing H.264 support anytime soon.
Hopefully the open/free nature means it'll be cheaper to integrate into lower end ARM IPs so that is not just the flagship Snapdragon and Exynos chips that offer AV1
Getting it into the hands of the top 5 Samsung devices would probably cover a significant market share (not to mention getting it into all Apple phones/tablets).
Indeed. I imagine some older codecs could be dropped though, and the cost saved on IP should offset it. I'm not sure what the comparative silicon size might be though so I can't speculate.
Is there a difference now? Websites in Safari ask me to pay with an Apple ID popup that takes my fingerprint and charges me exactly the same way apps do, I don't see any difference in how it appears or is handled.
"just going to be a big iPhone (...) lay back in bed and casually browse the web, read magazines, watch movies, play games? On something with a decently large screen" -- isn't that just a big iPhone, then? Especially now that the iPhones are fairly large themselves, and mobile layouts are almost universal. I have an iPad, but I've never really found a good use for it. Web browsing, reading, and watching videos I find more comfortable on a phone (or a Kindle) I can hold in one hand. The form factor of the iPad combined with its touch screen means I can never find a comfortable way of holding it long-term.
To me the big draw of the iPad is that it combines the simplicity of a phone OS with a screen that can render large fonts and still be usable. That's great for people with poor eyesight, like my grandparents, who can fit only a few words at a time onto a 5" phone display and who find the Windows interface frustrating (being full of small buttons, accidentally-pressed keyboard shortcuts, things minimizing to the tray, and multiple windows containing multiple tabs). As someone lucky enough to have escaped that problem so far the iPad exists in a strange halfway point between a laptop (large, powerful, keyboard-equipped, capable of running and doing anything) and a phone (comfortable, portable, long-lasting) that's never quite right for the job.
Admittedly I've never used the Pencil which I imagine can be quite nifty.
I have to say I disagree there. "Our program for handling HTML+CSS content should handle HTML+CSS content stored in containers" is a much more reasonable idea than "Our program for opening containers should also handle whatever content is inside those containers." It's a common thing for programs to do. VLC plays videos in zip files and RetroArch plays games in zip files, for example.
And I don't think reading a book and browsing the web are fundamentally different activities. They're near-identical. The web was created as a way to access documents consisting of text, images, and links to other points within the current document or to other documents. A book is a document consisting of text, images, and links to other points within the current document (endnotes, footnotes, "see page X") or to other documents (references/citations). The UX and features you'd want for a book reader are the same you'd want for a browser's Reader Mode, as implemented by Edge, Firefox, and Safari. I don't see any difference between reading an ePub file and reading a long article on a website.
Popular video file players have supported generating iframe tracks for fast forwarding and thumbnail scrubbing for many years now, is there something about the way eg MPCBE and PotPlayer operate that is somehow unreasonable?
It's terrible performance on a power limited devices. It either burns up your battery or is unreasonably slow. Particularly when the source stream is high resolution or complexity.
I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too:
- You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand).
- Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize.
- While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc.
- Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.