Our article Scientific notation claims that

The ALGOL 60 (1960) programming language uses a subscript ten "₁₀" [between the significand and the exponent of a number written in scientific notation], for example: 6.0221023. This presented a challenge for computer systems which did not provide such a character, so ALGOL W (1966) replaced the symbol by a single quote, e.g. 6.022'+23, and some Soviet ALGOL variants allowed the use of the Cyrillic letter "ю", e.g. 6.022ю+23. Subsequently, the ALGOL 68 programming language provided a choice of characters: E, e, \, ⊥, or ₁₀. The ALGOL "₁₀" character was included in the Soviet GOST 10859 text encoding (1964), and was added to Unicode 5.2 (2009) as U+23E8 ⏨ DECIMAL EXPONENT SYMBOL.

The part I have a question about is Soviet Algol variants allowing "ю" to be used for this purpose. This was originally added by NevilleDNZ in 2017 in special:diff/774402196, and I expect it is probably correct. But it has never had a source.

Since I don't read Russian, it's hard for me to track down sources about this. Can anyone find a source for this claim? –jacobolus (t) 03:43, 18 October 2026 (UTC)Reply

Aaccording to Google search, the Russian translation of the ALGOL 60 Report on Math-Net.Ru, "Сообщение об алгоритмическом языке АЛГОЛ-60" would confirm this. However, when trying to access this translation I get a timeout. It is quite conceivable – even likely – if it has been digitized, that the claimed "ю" is a scanno for ₁₀.  ​‑‑Lambiam 10:15, 18 October 2026 (UTC)Reply

@Lambiam: - the link worked for me. I have reuploaded it to Dropbox at this public url. Please let me know when you have it, so that I can delete the Dropbox copy. ~2026-56016-87 (talk) 15:42, 18 October 2026 (UTC)Reply

Got it, thank you. I've added it to my private repository of ALGOL 60 Reports.  ​‑‑Lambiam 17:59, 18 October 2026 (UTC)Reply

The difference between the bitmap text of the scan and its OCR version (in the table in 2.5.2 on page 314) seems to confirm your scanno suspicion. ~2026-56016-87 (talk) 15:51, 18 October 2026 (UTC)Reply

That seems to be just a straightforward translation of the English report, which doesn't (as far as I can tell, as a non-reader of Russian) describe anything specific to Soviet ALGOL implementations. I think we'd need something like a reference manual for the specific one(s) using ю, or maybe some kind of document comparing different varieties of ALGOL, but I don't know how to find such a thing. –jacobolus (t) 18:41, 18 October 2026 (UTC)Reply

Here is a screenshot of the relevant part from the PDF (File:Algol-number-examples.jpeg):

It's definitely '10', not a Cyryllic letter 'ю' there. --CiaPan (talk) 16:11, 19 October 2026 (UTC) (Edited 07:57, 28 October 2026 (UTC))Reply

See also Russian Wikipedia ru:Алгол#Числа (Algol # Language properties # Data types # Numbers), which mentions the subscript '10' but no 'ю' character in the floating-point number exponential notation. --CiaPan (talk) 13:01, 20 October 2026 (UTC)Reply

I'm not sure if this is something my pc has decided to do, or something Wikipedia has decided to do. Edge running on Win11. Monobook (global pref). I used to be able to start typing an edit summary, and previous edit summaries that started with the same letters were offered for me to click on and use. This no longer happens in article space and Wikipedia space. It does still happen in Template space, and indeed it offers me summaries I've used in all spaces. It would be very helpful to get this happening again in article space. Any ideas? Thank you, DuncanHill (talk) 22:29, 20 October 2026 (UTC)Reply

I can report that such suggestions are still offered to me, also for article-edit summaries. Perhaps the good people at the WP:TECHPUMP know more.  ​‑‑Lambiam 22:16, 21 October 2026 (UTC)Reply

Being older than dirt, I recall a time of not just floppy disks, but floppy floppy disks. These usually got sold with a sleeve to help protect the contents from dirt and moisture, etc. Many were simply white paper, but some were composed of something paper-like, but which had a kind of fabric within it. I think the two diskettes at the front of this image are of that type. What is it? I don't think I've ever seen it used elsewhere. It had a pleasant, soft, feel compared to plain paper. Pinging User:JIP as they are the uploader and have contributed here often. Matt Deres (talk) 00:55, 21 October 2026 (UTC)Reply

Tyvek? —Antonissimo (talk) 02:41, 21 October 2026 (UTC)Reply

Matt Deres (talk) 00:55, 21 October 2026 (UTC)Reply

• I no longer have that box of floppy disks, but as far as I can remember, yes, they were floppy floppy disks, where both the actual disk (round) and the protective coating (square) are bendable and not rigid. And yes, they were sold with a protective paper sleeve, which was little else than a simple paper sleeve to put the disk into to prevent dust and dirt getting on the actual disk. JIP | Talk 06:17, 21 October 2026 (UTC)Reply

My recollection of 5¼-inch floppies was that they came in a paper sleeve, but it had a slightly waxy texture - water resistant I suppose. Google AI says they were "typically made from heavy-duty paper, cardstock, or thin anti-static plastics like polyethylene or DuPont Tyvek," citing this page in solidarity Chuntuk (talk) 10:49, 21 October 2026 (UTC)Reply

Many were coated to reduce static. The coating could be anything from a wax coating to a latex coating to a clay coating, depending on what was cheapest as the paper sleeve was not the product being sold. I think the issue here is that the sleeves shown in the image here are card stock. They are not the flimsy white paper sleeves with that mottled semi-gloss appearance. ~2026-46630-01 (talk) 11:15, 21 October 2026 (UTC)Reply

No, what I'm talking about is more than a coating; the "paper" itself had fibre in it. I think Antonissimo is right and they were tyvek; an image search for tyvek floppy disk sleeve confirms it. Matt Deres (talk) 16:02, 23 October 2026 (UTC)Reply

Tyvek is likely, but pulp paper, such as the paper used in LP sleeves, is fibrous as well. I know what you are referring to. It is like the "paper" used for money, which is actually mostly cotton. But, the shiny surface leads more towards pulp paper. It used to be called rice paper, which is a misnomer. It is made from long-fiber pulp (like mulberry). ~2026-46630-01 (talk) 16:42, 23 October 2026 (UTC)Reply

No, it's not really like the material used for "paper" money, though it does have that softness to it. The fibers are much larger and clearly visible. Matt Deres (talk) 01:43, 24 October 2026 (UTC)Reply

I've written a web application using HTML, CSS, JavaScript, Node.js and Express. I'm looking for advice on URL design for pictures in my application.

Currently, the implementation works as follows:

• backend generates SVG avatars for given IDs and converts uploaded images to WebP
• backend generates picture URLs: /avatar/{id}.svg for automatically generated avatars and /media/{id}.webp for user-uploaded images
• server.js defines the corresponding routes: /avatar/:id.svg and /media/:id.webp
• the file format is already unambiguous from the endpoint and its implementation, even without an extension: /avatar/{id} would still refer to an SVG generated by the avatar handler, while /media/{id} would refer to a WebP image served by the media handler, and the server can communicate the actual format through the HTTP Content-Type header

Would you recommend keeping file extensions in these URLs or switching to extensionless, format-independent URLs? ~2026-56849-00 (talk) 22:24, 24 October 2026 (UTC)Reply

I'd keep the file extensions. The format may be unambiguous given the URL, but when downloaded, the disambiguating path segment is stripped off of the file name.  ​‑‑Lambiam 08:00, 27 October 2026 (UTC)Reply

How to http: and https: relate these days?

If a server prefers https, and I follow a link that has http:, the server will (always?) substitute https:. But what about the reverse? Not all websites have made the change. Will a http site do the right thing with a https: address? —Antonissimo (talk) 03:37, 29 October 2026 (UTC)Reply

See Transport Layer Security (TLS). This is the underlying tech that maintains privacy for the communication between a user's computer and the server. While some servers are configured to allow unencrypted (plain http) mode as fallback, doing so has security implications: this would make a man-in-the-middle attack feasible. For example, attacker eavesdropping on a user's connection half-way, taking the HTTPS request packet, and do something to it to make it fail to force a fallback to plain HTTP. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 05:29, 29 October 2026 (UTC)Reply

The automated upgrade from http: to https: may be due to your browser, rather than the server.  ​‑‑Lambiam 08:21, 29 October 2026 (UTC)Reply

It can also be in a router and corporate packet inspection. From the browser to the web server, there is long-standing history of automatically converting http traffic to https without asking the user.

But, I wanted to answer the question about how they relate. If you use http, your web request is unencrypted in transit. If you use https, your web request (the same request you made in http) is encrypted in transit. The standard format of encryption is TLS. What is important here is not that it is encrypted from your computer to the server. It is encrypted from your web browser to the web service running on the web server.

I also wanted to respond to the statement that not all website have made the change. That is true. It is expensive to implement https because you need a secure certificate on the server. You either pay in money or time. For around $1000, you can easily purchase a certificate that lasts years. For $0, you can spend hours fiddling with cryptic broken websites to try and get a certificate that lasts a few months and then you have to start over again, trying to run through the maze of more broken links, broken forms, and broken instructions... and tons of advertising that covers up that one button you were supposed to click five screens ago. Therefore, if you don't feel you need encryption on your website, why deal with it? ~2026-46630-01 (talk) 11:50, 29 October 2026 (UTC)Reply

Would https://www.akamai.com/blog/security-research/understanding-php2shell-everything-you-need-to-know and https://outcomeschool.com/blog/php2shell be considered reputable sources if I wish to draw a diagram explaining how PHP2Shell works, in a similar style to this explanation for Heartbleed? cmɢʟee τaʟκ (please add {{ping|cmglee}} to your reply) 00:13, 31 October 2026 (UTC)Reply

Akamai Technologies is a reputable company with long-standing expertise in the area of cybersecurity, so I think it can be considered a reliable source. I have no reason to doubt the accuracy of the explanation on the website of Outcome School by its founder, Amit Shekhar, a graduate of IIT (BHU) Varanasi. This school is a prestigious engineering institution, but I do not have evidence that Amit Shekhar has specific cybersecurity expertise, so it is less clear that this page can be considered a "reliable source" in the specific Wikipedia sense. As it aims at a more general public, it may still be a valuable resource in understanding the more detailed technical explanation on Akamai's security blog and condensing it to a simple diagram. CVE-2026-109619 is essentially a dangling pointer issue, so the (static) diagram in the article Dangling pointer may, perhaps, also be a source of inspiration.  ​‑‑Lambiam 11:53, 31 October 2026 (UTC)Reply