acqq

The changes, in sum, in nsXULTooltipListener.cpp

    -  if (tooltipNode->GetComposedDoc() &&
    -      nsContentUtils::IsChromeDoc(tooltipNode->GetComposedDoc())) {
    +   // Make sure the document still has focus.
    +   auto* doc = tooltipNode->GetComposedDoc();
    +   if (!doc || !nsContentUtils::IsChromeDoc(doc) ||
    +       !doc->HasFocus(IgnoreErrors())) {
    +     return NS_OK;
    +   }
    ...
    -   }
    }
    return NS_OK;

If I see correctly, all the changes are:

1) remembering result of tooltipNode->GetComposedDoc() and adding the test of doc->HasFocus(IgnoreErrors()). Note that writing this one now is maybe easier than it was at the time the initial code was written, it could be the "auto" in this current semantic didn't exist in C++ (or the used compilers/platforms) at that time.

2) Explicit return. Instead of:

    if (b)
      X;
    return OK;

now it's:

    if (!b)
      return OK;
    X;
    return OK; 

which in this case increases readability as X is in many lines and b is a more complex condition.

Regarding the DoubleSpace context, Wikipedia helps (1):

Sept 1991: Digital Research releases DR DOS 6.0 with AddStor's SuperStor disk compression.

March 1993: Microsoft introduces MS-DOS 6.0, the first with DoubleSpace disk compression

June 1993: IBM announces PC DOS 6.1

November 1993: Microsoft MS-DOS 6.2, leapfrogging IBM's PC DOS 6.1 and with improved the stability of DoubleSpace.

February 1994: Microsoft found guilty of patent infringement, and Stac Electronics guilty of trade secret theft. Microsoft MS-DOS 6.21, removing DoubleSpace.

June 1994: After a judge ordered Microsoft to recall all unsold infringing products worldwide, Microsoft settled its dispute with Stac, and released MS-DOS 6.22, bringing back disk compression with internally developed DriveSpace, which is about 5% slower than DoubleSpace.

An interesting detail:

In the MS-Stac trial, "Stac’s lawyers showed a videotape of Microsoft Chairman Bill Gates" "at the unveiling of MS-DOS 6.0 in which he wore a T-shirt saying, “We came, we saw, we doubled,” to underscore the importance of the compression feature." (2)

A second detail, the "trade secret theft" was:

Stac was found "to have committed a trade secret violation by reverse engineering features of a beta version of MS DOS that they had gotten in confidence and then using the information they gained in making their own product." (3)

1) https://en.wikipedia.org/wiki/Timeline_of_DOS_operating_syst...

2) https://www.latimes.com/archives/la-xpm-1994-02-24-fi-26671-...

3) https://lwn.net/Articles/134642/

And we come once again back to the start: _because_ there's an explicit algorithm right there in the standard which allows to start from something "not special" like the digits of Pi or even the ASCII strings of the beginning of the Declaration of Independence, why the completely opaque constants instead? Even if it's, as Filippo suggests, because "the counter has to be there because only one in every 192 to 521 hashes is actually good to make a curve out of", if the counter is a known part of the process of such a selection, all these details could still have been "open".

At least, that's my understanding why there's still talk about it all, and this bounty: those who don't like the opaque constants argue: why aren't they "open", if really "irrelevant"? Now, if the bounty shows that the constants come from something like

SHA-1("Jerry and Alice deserve a raise. 1398")

then all this looks a little better, especially if it can be shown that that "1398" was the first integer that "worked" for the selected phrase, according to the publicly known criteria.

> The claim here is that the procedure used for choosing the SEED in the first step involved SHA-1 of some ASCII text with a counter.

That's the story as much as I see it: there's a constant that doesn't appear to be "arbitrary" enough in a sense that there's a suspicion that it could be too "special" if nobody can recognize it, and nobody can show how that one was generated.

And as there's an official procedure to turn something to something "more random" that "something" appears to be still missing.

BTW I don't think that the "inefficiency" you see in the steps there changes anything.

I don't think we can complain that there were retries over different human-readable seeds to make an appearance of "verifiably at random" design if the chosen human-readable seeds just haven't been published at all.

And if the argument is that the publishing of human-readable seeds was unnecessary because the retries of the procedure could have been performed until some exploit was possible, why even define and publish these definitions? Was it an error? Or something else?

However, I don't find it funny reading all the "gory" details:

In the article, under the subtitle "Step back, what is this about?" is:

"The NIST elliptic curves (P-192, P-224, P-256, P-384, and P-521[1]) were published by NIST in FIPS 186-2 in 2000, and generated “verifiably at random” according to ANSI X9.62 by taking an arbitrary seed, hashing it with SHA-1, and using the output to derive some of the parameters."

Note the sentence: “verifiably at random” according to ANSI X9.62.

Now, the mentioned ANSI X9.62 describes very formal algorithms of what “verifiably at random” should mean:

"If it is desired that an elliptic curve be generated verifiably at random, then select parameters (SEED, a, b) using the technique specified in Annex A.3.3.1"

and then goes on to specify an exact algorithm both how the parameters are selected in A.3.3 and then in A.3.4 the verification algorithm: "The technique specified in this section verifies that the defining parameters of an elliptic curve were indeed selected using the method specified in Annex A.3.3"

So, if I understand correctly, the authors spent enough energy both to construct the algorithms to generate the constants and make the SEED public as well as the algorithms to later verify the parameters given the publicly known SEED as an input. And to publish all that in ANSI X9.62.

If that was the idea of “verifiably at random” according to ANSI X9.62, and if then nobody knows the SEED, then it appears that the very procedure, for which a lot of energy was spent to be developed or described, was just not followed. From which it can be concluded that the "if" condition of the sentence was just not true:

"If it is desired that an elliptic curve be generated verifiably at random..."

(Not to mention that the algorithms published there clearly aren't "simply SHA1 hashes" in the sense result = SHA1( seed ) but, casually looking, a concatenation of only some bits of output from multiple SHA1 runs over the increments of the seed, which could suggest that nobody who tries any human written string as a seed would ever find a result by expecting a match of a whole constant with an output of a single SHA1 pass? Has anybody calculated how big would be a chunk of bits from a single SHA1 run actually for every of the constants?)

Now, I probably miss something here, if it is so, I'd like to know what.

And here the plot up to August 2023:

https://svs.gsfc.nasa.gov/vis/a000000/a005100/a005161/GISTEM...

No. sixbrx explanation applies:

https://news.ycombinator.com/item?id=37772724

Count me too to the group of "I was so distracted that I stopped reading."

Then the second thought was: I should again start to block js by default as much as I can.

I'm simply not interested in person's later claims, the post does not contain any conditionals. That is exactly what I argue, let me repeat if it wasn't clear enough: if somebody "sees" them where they aren't it's due to their assumptions existing independently of what is actually written in the post.

I however think you can't cite any statement in that post directly containing that assumption, if it was "clear" to you it says more about your assumptions than about the actual content discussed.

> You are misstating their position

I'd say you are doing it to both his an mine.

> Big emphasis on IF

I don't see any conditional in that post AT ALL. The paragraph starts with the explicit invitation and also states the (false and, let's be clear, if targeted at most other ethnicities/nations, immediately recognized as profoundly racist) "reason": "I just hope NATO ... actually go all the way and occupies the country. That's the only way to neuter Serbia for a generation of two ..."

Put as a thought example Native Americans in these sentences and consider how it was "better" for them to be eliminated, and how a text of anonymous self-claimed "Native American" saying that sentence targeted at their own people would appear today.

If it wasn't clear enough: your ethnicity, whether claimed or factual doesn't make your claims more or less valid.

The choice of names, however, reflects in this case a political side of a writer. Even if the cause is mere "autocorrect" I still claim the autocorrect sublimes your political views correctly, and I never claimed that you hide them. On the contrary, they can't be more obvious, inviting literal occupation: "I just hope NATO ... actually go all the way and occupies the country."

Inviting a war is a terrible position, good only for those who, ignoring all the bodies of the victims, profit from them. Long term, neither war inside own borders nor occupation resulted in the net benefit of the attacked and/or occupied nations. Any claims to the opposite stem from the specific political agenda, which I invite the readers to be aware of in discussions with political consequences.

> northern Kosova

Readers should note that the above post used the _Albanian_ form of this name, and compare with the Britannica's reference:

https://www.britannica.com/place/Kosovo

"The name Kosovo is derived from a Serbian place-name meaning “field of blackbirds.” After serving as the centre of a medieval Serbian empire, Kosovo was ruled by the Ottoman Empire from the mid-15th to the early 20th century, a period when Islam grew in importance and the population of Albanian speakers in the region increased."

Then research the political background behind the recent use of "Kosova" form.

Also:

BBC: "Kosovo: Why is violence flaring between ethnic Serbs and Albanians?"

https://www.bbc.com/news/62382069

> one in particular (a Roman named Oursenplus) that I only finally got when I heard a French colleague say it out loud (with a "sh" sound at the end rather than "ss")

Be kind to us who still don't know enough and explain it here.

Thanks!

https://press.uchicago.edu/ucp/books/book/chicago/I/bo141943...

From the book's "Chapter 7. Modern Archaeology -- Putting the Evidence of the Alphabet in Place"

"We can now describe the origin of the alphabet chronologically and geographically with some degree of reliability. The basic outlines are these: The alphabet was formed in the context of cultural exchanges between Semitic-speaking people from the Levant and communities in Egypt after or around 1800 BCE. The earliest evidence is dated to Wadi el- Hol, a site in Egypt just west of the Nile, north of Luxor. Later inscriptions in the Sinai and throughout the Fertile Crescent show the gradual distribution and evolution of alphabetic writing, with most evidence dating from the fourteenth century BCE and after."

Regarding "how much do we really care what various scholars in the 16th Century made up about the history of the alphabet?" we should, if we're interested in knowing the context in which various claims, which pop up even today, appeared for the first time. The context often explains the motivation which resulted in specific "made up" narrations, some still (often unfortunately) influencing our lives.

TIL

"You've Heard of Smallpox, But What Was the Great Pox?" (2018)

https://entertainment.howstuffworks.com/arts/literature/pox-...

"The Great Pox that was…syphilis" (2001)

https://ami-journals.onlinelibrary.wiley.com/doi/abs/10.1046...

Testing with 100 MB set from mattmahoney.net and relatively comparable sizes pzip is twice as fast as the previously mentioned Pavlov's 7z, that's clearly useful for those who need the fastest possible creation of a "classic" zip with compressed files, when lower compression ratio (1.6 MB bigger compressed file when compressing 100 MB set, compared to 7z) is acceptable.

    $ time zip -2 -r a-zip.zip 100mb/ >/dev/null
    real user sys: 2,1 1,8 0,1 
    $ time 7z -tzip -mx=1 a a-7z-1.zip 100mb/ >/dev/null
    real user sys: 1,0 2,7 0,0 
    $ time ../pzip a-pzip.zip 100mb/ >/dev/null
    real user sys: 0,5 1,0 0,1 
    $ L a
    48197707 a-7z-1.zip
    49921626 a-pzip.zip
    49553097 a-zip.zip

If the "classic" (i.e. the goal to unpack the archive using older programs) compatibility is not important, it could be interesting to consider that at least since 2020 zstd is officially a "standard" method for ZIP files too, allowing even faster compression speed for the same compression size targets.

    93 - Zstandard (zstd) Compression 

https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.9.TX...

I'm aware that there are some attempts of modifications of 7zip to allow using that method in ZIP files, but I don't know more than that:

https://github.com/mcmilk/7-Zip-zstd

https://github.com/mcmilk/7-Zip-zstd/issues/132

https://github.com/libarchive/libarchive/issues/1403

If ZIP target format is not a condition, here's the speed of using zstd on tar for the same input and approximately the same resulting size:

    time tar -c 100mb | zstd -2 -o a.tar.zst 2>/dev/null
    real user sys: 0,4 0,4 0,1 
    48585639 a.tar.zst

7-Zip by Igor Pavlov can create zip files, has multi-threading and in my small test, comparing with the "pzip", was both as fast in "real" time and produced smaller file (while using similar amount of CPU but differently distributed between user and sys).

https://www.7-zip.org/download.html

Also, in my example the compression level of Info-Zip that best matched the one in pzip was -3 This can, of course, depend on the set.

    ~/c/measure_pzip$ time 7z -tzip -mx1 a a7.zip /usr/lib/apache2/*

    7-Zip (z) 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
     64-bit locale=en_US.UTF-8 Threads:3 OPEN_MAX:1024, ASM

    ...

    real 0m0,074s
    user 0m0,121s
    sys 0m0,014s
    ~/c/measure_pzip$ time ./pzip a-p.zip /usr/lib/apache2/*

    real 0m0,073s
    user 0m0,097s
    sys 0m0,038s
    ~/c/measure_pzip$ time zip -3 -r a-zip.zip /usr/lib/apache2/ >/dev/null

    real 0m0,118s
    user 0m0,114s
    sys 0m0,004s

    ~/c/measure_pzip$ ls -l a*.zip | ./my2
    1576511  a7.zip
    1619733  a-p.zip
    1613607  a-zip.zip

Allowing for 2% bigger resulting file could mean huge speedup in these circumstances even with the same compression routines, seeing these benchmarks of zlib and zlib-ng for different compression levels:

https://github.com/zlib-ng/zlib-ng/discussions/871

IMO the fair comparison of the real speed improvement brought by a new program is only between the almost identical resulting compressed sizes.

Do you know which distributions are using zlib-ng for zip and unzip programs?

If I understand, the improvement would be around 3 times less CPU use for the comparable resulting size, but I see it here shown for "minizip" not zip:

https://github.com/zlib-ng/zlib-ng/discussions/871

Note that even when not considering the speedup due to the compression happening in multiple threads, the libraries used for compression here use much less CPU (user 3m33s) than "the standard zip utility" (user 13m13s i.e. 3.7 times the former -- if I understand correctly, this "standard" is Info-ZIP) which is a little less surprising knowing that the source for the later hasn't been updated for 15 years, while, if I understand correctly, this new go version depends on the compression routines maintained in https://pkg.go.dev/compress/flate

I also don't see the comparison of the resulting compression sizes of the two programs.

It's as designed:

"Both teams identified the carbon dioxide using data from the integral field unit of Webb’s Near-Infrared Spectrograph (NIRSpec). This instrument mode provides spectra with a resolution of 200 x 200 miles (320 x 320 kilometers) on the surface of Europa, which has a diameter of 1,944 miles"

The article is very precise:

"Both teams identified the carbon dioxide using data from the integral field unit of Webb’s Near-Infrared Spectrograph (NIRSpec). This instrument mode provides spectra with a resolution of 200 x 200 miles (320 x 320 kilometers) on the surface of Europa, which has a diameter of 1,944 miles, allowing astronomers to determine where specific chemicals are located."

Wikipedia article about the NIRSpec:

https://en.wikipedia.org/wiki/NIRSpec

There was at least one popular home computer which was never just text mode but booted in permanent bitmapped graphic mode, directly in BASIC line editor. Entering a command would execute immediately, entering it with the line number in front would add that line to the program.

So right after boot a single command could draw a line or a circle. One was not supposed to even type the letters for any command, but had to enter it like on the pocket calculators: the commands were written on the keyboard, in more colors, so just looking at the keyboard one directly saw all the available commands.

The barrier there was learning to enter the needed mode to reach the appropriate color and learning the syntax and the meaning of the commands.

Every user learned to enter at least one command and its syntax: the one which allowed loading any program from the tape. It was a full command with the empty string parameter meaning "match any name": LOAD ""

Printed text on _scrolls_?

> I believe that curl does not have client side caching

See:

https://news.ycombinator.com/item?id=37528558

by llimllib

Specifically:

   curl  -o /tmp/euro.zip -z /tmp/euro.zip

Option o is output, option z says

"Request a file that has been modified later than the given time and date, or one that has been modified before that time."

And:

https://news.ycombinator.com/item?id=37529690

by sltkr:

"the server doesn't support that header, but since the response does include a Last-Modified header, curl helpfully aborts the transfer if the Last-Modified date is the same as the mtime of the previously downloaded file."

Also, on the topic of range requests, when a server allows the range requests for zip files, the zip files are huge and one needs just a few files from them, one can actually download just the "central directory" and the compressed data of the needed files without downloading the whole zip file:

https://github.com/gtsystem/python-remotezip

> “I’m absolutely shocked we’re seriously discussing that a European state could have done this,” says Ivan Kolpakov, Meduza’s editor-in-chief. “I’m probably naive"

Rather then naive, I think his main problem is that he hasn't investigated before the discussed event what the European states actually do in that context. Then he would be just worried, not shocked.

Another possibility is that the "shocked" is the "Casablanca shocked":

> Rick: How can you close me up? On what grounds?

> Captain Renault: I'm shocked, shocked to find that gambling is going on in here!

> [a croupier hands Renault a pile of money]

> Croupier: Your winnings, sir.

> Captain Renault: Oh, thank you very much.

Instead of speaking of own feeling based on a "section" the rational approach is to read the actual scientific paper dealing only with that topic:

https://pubs.acs.org/doi/10.1021/acs.est.1c04158

"Outside the Safe Operating Space of the Planetary Boundary for Novel Entities"

Environ. Sci. Technol. 2022, 56, 3, 1510–1521