Yes, I'm aware. The problem with anchors is that the author has to take care to make them both unique and human-readable across the whole document. The problem with URL text fragments is that they generally become too long to be a citation. Both need quality-of-life improvements in the tooling before academics will consider using them.
For example, it's pretty easy to use CSS counters to create as many automatically incrementing counters as you need. Page number, section number, theorem number, etc. But (a) you can't do this in raw HTML, which means you can't rely on this working in any user agent that has poor support for CSS; and (b) you can't refer to the values of those counters outside of CSS. Thus, there's no way for you, as an author, to write the write the equivalent of LaTeX's "See Theorem~\ref{thm:foo}" in HTML and rely on having it auto-numbered and rendered correctly wherever your readers are. So the number has to already be there as text in the HTML, and you need a separate, document-unique id attribute coordinated with the number to use for linking. This means you need a separate compilation step to produce the HTML, so you've lost pretty much the only advantage that HTML had over LaTeX.
But fundamentally, the problem is that citation practices assume that the reading format is controlled by the author/publisher, so that all readers are looking at a common view of the document, whereas the Web assumes that the reading format is controlled by the user agent, and user agents vary widely. Thus, on the Web, you need formatting-independent citation practices, which have not yet evolved, or at least not become widely used, because it's too hard compared to page-based media, which have been working for centuries.
Citations. Until we can cite specific passages in HTML as quickly, easily and readably as we can cite pages in paged media, HTML will remain a second class citizen for serious scholarship.
I don’t need it with me all the time; I‘d prefer to just log in to a website on a real computer! But you can’t do this in the EU in practice without a banking app on a phone, or some other piece of hardware that you have to pay extra for and is certainly not more convenient.
Right, I suppose this is theoretically possible here too (I'm in Austria), though I haven't looked into it that carefully, because all the options here seem to cost more than my current bank account and as far as I can tell still require a smartphone.
I wouldn't necessarily mind a dedicated piece of hardware, but if it's dedicated hardware, I feel like the bank ought to provide it, not make me pay for it. And I'd much rather it be a generic piece of hardware that can also be used as a second authentication factor for other things, like a Yubikey. I've looked around but have not found any banks that offer this. The only one I had heard of no longer offers it.
Sure, the world is a better place with fewer serfs in it, but what exactly is of "higher value" than being a research mathematician? It's already a profession that consists essentially of exercising our highest and most distinctly human capacities: creativity, abstract reasoning, and passing the results of those on through a distinctive language and culture. I don't think the comparison with serfs is useful.
I'm sure most research mathematicians would like more freedom from some of the drudgery of their work (grading, admin, etc.), just like the rest of us. But we should be aiming for a world that allows more people to become mathematicians, not fewer.
I love the idea and wish I could get something like this in Europe. The main reason I "need" a smartphone over here is that EU banking regulations make it nearly impossible to do online banking without one. Anyone know of similar projects over here that would satisfy that need?
Presumably the 40mb of data is not from Wikipedia, but the Javascript tracking code bundle needed to turn it into a doomscrollable social media feed. ;) By those standards, I think it’s pretty lightweight! For comparison, the Instagram iOS app is 468.9mb, more than ten times the size…
I have been working on implementing iCalendar/RFC5545 in Emacs Lisp. I recently submitted a large patch and hope it will be merged in the next couple of months:
This will add an iCalendar library to GNU Emacs, allowing packages in core and third-party packages to work with the format. More on the decisions I made and what I learned here:
Yes, that's what's going on: job titles are typically gendered in German, which leads to job ads being written in an awkward way to express gender neutrality. For example, "engineer" has both a masculine form "Ingenieur" and a feminine form "Ingenieurin", so a job ad might say something like "Ingenieur*in (m/w/d)" to mean "an engineer of any gender".
The distinction between "first order" and "second order" is in the first instance a distinction at the level of formal languages. A second order language has more complicated syntax and semantics: it allows variables in predicate position, which (in the standard semantics) take values from the entire powerset of the underlying domain.
This makes second order languages, including the language of arithmetic, much more expressive: they can distinguish models that first order languages can't. Those infinitely many non-isomorphic models of arithmetic expressed in a first order language can be distinguished, and excluded, as models of arithmetic expressed in a second order language. That's why second order arithmetic is categorical: all of its models are isomorphic.
Yes, a model of second order arithmetic contains a model of first order arithmetic, but within the second order language, you can say "which model it is" (up to isomorphism). It's only if you restrict yourself to a first order language that you can no longer say anything which will be true in that model, but false in any non-isomorphic one.
> Usability issues of dispersed content include:...
> Increased cognitive load
> Difficulty building a conceptual model for the page
This completely agrees with my own experience. But if these things are true when viewing a "dispersed content" site on a desktop browser, shouldn't they be just as true on mobile? It seems to me that this is a big problem with mobile-first design in general: it's just not the right format for actually conveying conceptual information to users.
I've had tinnitus for about two years. Like you, I just kind of noticed it upon waking up one day. I don't know what caused it but it seems to be related to stress, posture, and sleep position. I'm still figuring it out, but it doesn't bother me that much, so I've been kind of slow with it.
Earlier this year I came across this study with very promising results:
Sirh, Soo Ji, So Woon Sirh, Hah Yong Mun, and Heon Man Sirh. 2022. “Integrative Treatment for Tinnitus Combining Repeated Facial and Auriculotemporal Nerve Blocks With Stimulation of Auditory and Non-Auditory Nerves.” Frontiers in Neuroscience 16. https://www.frontiersin.org/article/10.3389/fnins.2022.75857....
They found an acupuncture-based treatment which eliminates or significantly reduces tinnitus in more than 87% of cases (n=55). I'm hoping to be able to get this at some point. The study is out of South Korea though; it might be a while before the technique is available in the west.
I also read the Dawn of Everything and wanted to recommend it here. The first chapter drew me in immediately: reading the native American critiques of the culture of European settlers was eye-opening. By the end of the book I felt they had beat their message to death a little bit, but the message was a very interesting one.
I saw a photo exhibition [1] about the construction of the Bay Bridge once, containing many beautiful shots from the point of view of the workers. The photos were taken by Peter Stackpole, a 20 year old kid who basically just talked his way onto the boats that took the workers out to the site. He took photos of the towers as they were being riveted together, of the cables being wound. The photos are amazing and beautiful, but they show how dangerous the working conditions were.
When someone fell off and died, the workers would take the rest of the day off, but be back on the job the next day.
We don't accept that kind of risk anymore in the US, which obviously drives up construction costs. But it's hard for me to see that as a bad thing, and I bet that if you went and talked to the "builders" today, they'd prefer those costs to the ones we paid in the 1930s.
But my whole point was that they wouldn't be hosting content. The users would be hosting it themselves, on their local computers, serving it via their browser. Mozilla would just have to provide a way to give users a stable base URL (linked maybe to Firefox accounts) that they could give to other people.
This is a great idea, but the big problem with Beaker is the network effects: only Beaker users can see other Beaker users' sites. To be successful, I think the idea needs to run over regular HTTP(S) so that other browsers can still access these personal sites. This means, at least at the beginning, that someone needs to run the infrastructure that maps stable URLs to a P2P connection to individual browsers. Mozilla is in a good position to do that.
I agree with most of this vision, think these values are important, and would love to see Mozilla realize them.
Given the values outlined here, I was sad to see that Mozilla doesn't seem to be looking much beyond the centralized platforms of today's commercial web. They see the "minimal barriers to entry for both users and publishers" as one of the key properties that makes the web such an important communication medium, and "Site-Building Ergonomics" is a top-level area where they see possibilities for improvement. Despite this, I don't see any recognition that it's still too difficult for ordinary users to publish their own information, which is why we have big commercial platforms where people do this, funded by ads, with all the problems that come along with that.
I think the most revolutionary thing Mozilla (and other browser makers) could do to realize this vision would be to turn their browser into a publishing platform. Browsers already have excellent tools for editing HTML, CSS, and JS built in, and they already speak the relevant protocols. Why not give every user a base URL for their personal site, and serve pages under it directly from the browser running on their computer? That would really lower the barrier to entry for users to become publishers and help realize the values of Openness and Agency.
Of course, such sites wouldn't be available 100% of the time, but they would probably be available enough to cover most of things people use the big platforms for: sharing text, photos and videos with their family and Internet friends. They would not need to be ad-supported and wouldn't raise the associated privacy issues. There are other problems to solve, but Mozilla is uniquely qualified to solve them.
Public transportation does enable drinking. That is one reason why young people move to, and like to live in, cities with public transportation.
But there are still huge, important differences between public transport and "ride sharing". Public transportation almost never takes you point to point. You are expected to navigate public transportation on your own, including getting in and out at the right stops. Public transportation usually has sharply reduced service several hours before bars close. You also need a ticket, which often means you must be sober enough to work a machine that only takes cash.
If public transport is your ride home, you need to be a lot more sober than the people the author is writing about.
There are important differences compared to taxis, too. To take a taxi, you must (often) be prepared to pay in cash. You must have enough verbal control to give your address.
It is not implausible that ride sharing apps enable a kind of binge drinking that is qualitatively different from the kind people do when they have to take another way home.
For example, it's pretty easy to use CSS counters to create as many automatically incrementing counters as you need. Page number, section number, theorem number, etc. But (a) you can't do this in raw HTML, which means you can't rely on this working in any user agent that has poor support for CSS; and (b) you can't refer to the values of those counters outside of CSS. Thus, there's no way for you, as an author, to write the write the equivalent of LaTeX's "See Theorem~\ref{thm:foo}" in HTML and rely on having it auto-numbered and rendered correctly wherever your readers are. So the number has to already be there as text in the HTML, and you need a separate, document-unique id attribute coordinated with the number to use for linking. This means you need a separate compilation step to produce the HTML, so you've lost pretty much the only advantage that HTML had over LaTeX.
But fundamentally, the problem is that citation practices assume that the reading format is controlled by the author/publisher, so that all readers are looking at a common view of the document, whereas the Web assumes that the reading format is controlled by the user agent, and user agents vary widely. Thus, on the Web, you need formatting-independent citation practices, which have not yet evolved, or at least not become widely used, because it's too hard compared to page-based media, which have been working for centuries.