By: Rob Thorpe (noone.delete@this.nowhere.com), July 15, 2020 11:23 am
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on July 15, 2020 10:46 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on July 15, 2020 2:26 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 15, 2020 1:37 am wrote:
> > > Maynard Handley (name99.delete@this.name99.org) on July 14, 2020 12:40 pm wrote:
> > > >
> > > > Let's ask some simpler questions.
> > >
> > > Here's a simple question for you: can you never really admit that Apple does something wrong?
> > >
> > > They literally picked the worst possible thing you could do with filenames.
> > > Really. They corrupt fundamental user data. And you want to ask "simple questions"
> > > when nobody else has ever done anything as stupid as they did..
> > >
> > > I knew you were likely going to do the apologia thing, but Christ... It would be nice if you once
> > > in a while could avoid disappointing people with your incessant and rabid one-sided fanboism.
> > >
> > > > Are you against the concept of filename normalization generically?
> > >
> > > I will state unequivocally that it's both unnecessary and horribly stupid to do at an OS level, yes.
> > >
> > > And if you have to do it (hint: you don't. Really. Not even if you want to be case-insensitive), for the
> > > love of all that is holy, don't pick the absolute worst possible kind of normalization like Apple did.
> > >
> > > Others have done it better. Literally everybody else did. Decades before Apple screwed it up.
> > >
> > > > So you don't just want no normalization
> > > > of capitalization, you want name+' to be treated a
> > > > separate filename from namé ?
> > >
> > > You are apparently too ignorant and stupid to even understand the difference
> > > between comparing something as equal and considering them she same name, and
> > > forcing a particular normalization (and a particularly stupid one) on people.
> > >
> > > Here's a hint: an OS can choose to say that it considerers the file names "And" and "and" to be the same.
> > >
> > > That's case-insensitive and it's a big pain, but there are
> > > (bad) historical reasons to do so. Capitalization matters.
> > >
> > > But notice how case-insensitive comparisons are not "normalization". You
> > > can still call your file "And", and the system preserves the case.
> > >
> > > Internally, to do the case-insensitive compare, there may be hidden normalization
> > > going on (ie the comparison may be done by comparing every character turned to
> > > upper-case), but that normalization isn't visible or forced on the user.
> > >
> > > So the user can choose to have CamelCase file names. Sounds good? Sure, you can also
> > > then open it using "camelcase", and there are problems with that too (really), but
> > > this is at least considered generally fairly acceptable and understandable.
> > >
> > > Notice: the above does not normalize the names. It preserves the case, it just doesn't
> > > consider it important for name comparisons. Two different things entirely.
> > >
> > > Now, as the ignoramus you are, you go "but that's what Apple does!".
> > >
> > > Would you admit that Apple did something wrong if it always turned all filenames into ALL UPPERCASE?
> > >
> > > You'd find that really horrible, wouldn't you?
> > >
> > > And that is exactly what Apple is doing, just at a different level. Apple is indeed
> > > case preserving, but not normalization-preserving. And they not only mess with normalization,
> > > they literally pick the worst possible one that nobody sane would pick.
> > >
> > > And exactly like you don't need to turn all filenames into UPPER-CASE in order to compare
> > > them, you absolutely don't need to turn all utf-8 into NFD to compare them.
> > >
> > > It really is kind of the ASCII equivalent to not just always picking the upper-case name (which
> > > is kind of reasonable and historic if you want to normalize case), but literally then pickibg
> > > some other internal format that everybody will have to convert back from when using it.
> > >
> > > It's really not that different from saying "not only will we turn your "Abc" filename
> > > into "ABC", but we'll do it in EBCDIC because that's what we do internally", and
> > > making the argument that EBCDIC is very traditional and thus sensible.
> > >
> > > But you fundamentally physically cannot understand that this would be a problem, can you?
> > > Because in your world Apple can never make a mistake. So you must come up with these "simple
> > > questions" to try to show how what Apple did was right and proper, don't you?
> > >
> > > Linus
> >
> > Your rant would be much more understandable to people like me that never wrote a single
> > OS X program (or even to those who wrote OS X programs, but were never particularly concerned
> > with handling of file names) if you give just one example of of what's wrong.
> > That is, I can google NFD, but want to understand why OS X use of NFD is bad for git.
> >
>
>
> I agree, I'm curious about this but the rant to signal ratio is too high to get meaningful information.
> Like you I saw the reference to 'NFD', wondered "what the hell is that?" (is it obvious I know
> nothing about UTF-8 yet?) and learned that Linux and most everyone uses NFC encoding (which I
> also had never heard of before) by default while OS X uses NFD encoding by default.
>
> I have no idea what the difference is, why there are two choices if there's a case to be made that choosing
> one of the choices is a bad idea (other than "everyone else chose the other one so you should too") and if
> there are any good reasons why someone might make the other choice despite the compatibility issues.
>
> In my googling I saw multiple claims that HFS+ is NFD only (and NFC is converted to NFD)
> while APFS can use either NFC or NFD. Not sure the ability to use both makes the problem
> go away in Apple's newer filesystem, doesn't help, or makes things worse however.
Let's say you have a file with a name like "Amélie" or "Ångström". I OS-X that gets converted to NFD form, so the things above the letters get converted into separate Unicode code-points.
The point Linus is making is that this conversion is not two-way. That means that two different words can get converted into the same word. That also means that two different filenames could be converted to the same filename. So, in Linux you can have a file called Ångström.txt where the first letter is "ANGSTROM SIGN". In the same directory you can have a file with the same name where the Å is "LATIN CAPITAL LETTER A WITH RING ABOVE". In HFS+ you can't you can only have the A with the ring-above as two separate codepoints. So, you can only have one file. When you see an Å which form did it originate from? You can't know.
A version control system has to compare each part of a file to the original. Not just that contents but also metadata like the name. So, what happens when a file with one of the Ås I mention above is copied down to a HFS+ file-system? In that case it gets converted. Then what is supposed to happen when it gets copied back the other way? There is now no information to convert back to the right character. That's especially true on a distributed version-control system. Conceptually there is no central server, everything is on the same level.
> Michael S (already5chosen.delete@this.yahoo.com) on July 15, 2020 2:26 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 15, 2020 1:37 am wrote:
> > > Maynard Handley (name99.delete@this.name99.org) on July 14, 2020 12:40 pm wrote:
> > > >
> > > > Let's ask some simpler questions.
> > >
> > > Here's a simple question for you: can you never really admit that Apple does something wrong?
> > >
> > > They literally picked the worst possible thing you could do with filenames.
> > > Really. They corrupt fundamental user data. And you want to ask "simple questions"
> > > when nobody else has ever done anything as stupid as they did..
> > >
> > > I knew you were likely going to do the apologia thing, but Christ... It would be nice if you once
> > > in a while could avoid disappointing people with your incessant and rabid one-sided fanboism.
> > >
> > > > Are you against the concept of filename normalization generically?
> > >
> > > I will state unequivocally that it's both unnecessary and horribly stupid to do at an OS level, yes.
> > >
> > > And if you have to do it (hint: you don't. Really. Not even if you want to be case-insensitive), for the
> > > love of all that is holy, don't pick the absolute worst possible kind of normalization like Apple did.
> > >
> > > Others have done it better. Literally everybody else did. Decades before Apple screwed it up.
> > >
> > > > So you don't just want no normalization
> > > > of capitalization, you want name+' to be treated a
> > > > separate filename from namé ?
> > >
> > > You are apparently too ignorant and stupid to even understand the difference
> > > between comparing something as equal and considering them she same name, and
> > > forcing a particular normalization (and a particularly stupid one) on people.
> > >
> > > Here's a hint: an OS can choose to say that it considerers the file names "And" and "and" to be the same.
> > >
> > > That's case-insensitive and it's a big pain, but there are
> > > (bad) historical reasons to do so. Capitalization matters.
> > >
> > > But notice how case-insensitive comparisons are not "normalization". You
> > > can still call your file "And", and the system preserves the case.
> > >
> > > Internally, to do the case-insensitive compare, there may be hidden normalization
> > > going on (ie the comparison may be done by comparing every character turned to
> > > upper-case), but that normalization isn't visible or forced on the user.
> > >
> > > So the user can choose to have CamelCase file names. Sounds good? Sure, you can also
> > > then open it using "camelcase", and there are problems with that too (really), but
> > > this is at least considered generally fairly acceptable and understandable.
> > >
> > > Notice: the above does not normalize the names. It preserves the case, it just doesn't
> > > consider it important for name comparisons. Two different things entirely.
> > >
> > > Now, as the ignoramus you are, you go "but that's what Apple does!".
> > >
> > > Would you admit that Apple did something wrong if it always turned all filenames into ALL UPPERCASE?
> > >
> > > You'd find that really horrible, wouldn't you?
> > >
> > > And that is exactly what Apple is doing, just at a different level. Apple is indeed
> > > case preserving, but not normalization-preserving. And they not only mess with normalization,
> > > they literally pick the worst possible one that nobody sane would pick.
> > >
> > > And exactly like you don't need to turn all filenames into UPPER-CASE in order to compare
> > > them, you absolutely don't need to turn all utf-8 into NFD to compare them.
> > >
> > > It really is kind of the ASCII equivalent to not just always picking the upper-case name (which
> > > is kind of reasonable and historic if you want to normalize case), but literally then pickibg
> > > some other internal format that everybody will have to convert back from when using it.
> > >
> > > It's really not that different from saying "not only will we turn your "Abc" filename
> > > into "ABC", but we'll do it in EBCDIC because that's what we do internally", and
> > > making the argument that EBCDIC is very traditional and thus sensible.
> > >
> > > But you fundamentally physically cannot understand that this would be a problem, can you?
> > > Because in your world Apple can never make a mistake. So you must come up with these "simple
> > > questions" to try to show how what Apple did was right and proper, don't you?
> > >
> > > Linus
> >
> > Your rant would be much more understandable to people like me that never wrote a single
> > OS X program (or even to those who wrote OS X programs, but were never particularly concerned
> > with handling of file names) if you give just one example of of what's wrong.
> > That is, I can google NFD, but want to understand why OS X use of NFD is bad for git.
> >
>
>
> I agree, I'm curious about this but the rant to signal ratio is too high to get meaningful information.
> Like you I saw the reference to 'NFD', wondered "what the hell is that?" (is it obvious I know
> nothing about UTF-8 yet?) and learned that Linux and most everyone uses NFC encoding (which I
> also had never heard of before) by default while OS X uses NFD encoding by default.
>
> I have no idea what the difference is, why there are two choices if there's a case to be made that choosing
> one of the choices is a bad idea (other than "everyone else chose the other one so you should too") and if
> there are any good reasons why someone might make the other choice despite the compatibility issues.
>
> In my googling I saw multiple claims that HFS+ is NFD only (and NFC is converted to NFD)
> while APFS can use either NFC or NFD. Not sure the ability to use both makes the problem
> go away in Apple's newer filesystem, doesn't help, or makes things worse however.
Let's say you have a file with a name like "Amélie" or "Ångström". I OS-X that gets converted to NFD form, so the things above the letters get converted into separate Unicode code-points.
The point Linus is making is that this conversion is not two-way. That means that two different words can get converted into the same word. That also means that two different filenames could be converted to the same filename. So, in Linux you can have a file called Ångström.txt where the first letter is "ANGSTROM SIGN". In the same directory you can have a file with the same name where the Å is "LATIN CAPITAL LETTER A WITH RING ABOVE". In HFS+ you can't you can only have the A with the ring-above as two separate codepoints. So, you can only have one file. When you see an Å which form did it originate from? You can't know.
A version control system has to compare each part of a file to the original. Not just that contents but also metadata like the name. So, what happens when a file with one of the Ås I mention above is copied down to a HFS+ file-system? In that case it gets converted. Then what is supposed to happen when it gets copied back the other way? There is now no information to convert back to the right character. That's especially true on a distributed version-control system. Conceptually there is no central server, everything is on the same level.
Topic | Posted By | Date |
---|---|---|
Alder Lake and AVX-512 | me | 2020/07/11 07:02 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 11:41 AM |
informative (NT) | blue | 2020/07/11 12:40 PM |
grumpy | Michael S | 2020/07/11 12:51 PM |
grumpy | me | 2020/07/11 01:27 PM |
area and power cost of AVX-512 | Michael S | 2020/07/11 12:58 PM |
area and power cost of AVX-512 | Anon | 2020/07/11 04:35 PM |
area and power cost of AVX-512 | Michael S | 2020/07/12 04:16 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/12 09:13 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/11 07:19 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 02:02 PM |
Alder Lake and AVX-512 | Ungo | 2020/07/11 05:28 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 10:16 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:51 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 01:48 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:07 PM |
HDR | Anon3 | 2020/07/12 03:42 PM |
HDR10 in Kaby Lake? | David Kanter | 2020/07/12 05:09 PM |
HDR10 in Kaby Lake? | Maynard Handley | 2020/07/12 06:13 PM |
Thanks for the link (NT) | David Kanter | 2020/07/12 06:43 PM |
HDR10 in Kaby Lake? | Anon3 | 2020/07/13 01:36 AM |
Alder Lake and AVX-512 | Dummond D. Slow | 2020/07/12 03:00 PM |
AVX-512 with narrow ex units? | m | 2020/07/23 12:10 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 12:53 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 06:50 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 07:45 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 08:15 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/24 04:44 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/24 02:56 PM |
AVX-512 with narrow ex units? | Jouni Osmala | 2020/07/24 09:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/25 01:32 AM |
AVX-512 with narrow ex units? | Eugene Nalimov | 2020/07/25 05:56 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/26 01:28 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/26 02:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/27 07:00 AM |
AVX-512 with narrow ex units? | -.- | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Travis Downs | 2020/07/24 05:01 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 04:45 PM |
Alder Lake and AVX-512 | Chester | 2020/07/11 05:26 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 06:22 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:02 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:54 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:01 PM |
Alder Lake and AVX-512 | N Owen | 2020/07/12 12:37 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:48 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 07:13 PM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:09 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:42 PM |
Alder Lake and AVX-512 | Doug S | 2020/07/11 11:49 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:53 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 07:03 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/11 07:43 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:31 AM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:01 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 03:26 PM |
Alder Lake and AVX-512 | Anon3 | 2020/07/12 04:07 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:39 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:21 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:33 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 05:54 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 06:20 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/12 07:32 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 08:41 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/13 04:02 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/13 07:25 PM |
PentiumMMX vs Transmeta's VLIW in hindsight | ⚛ | 2020/07/19 06:16 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | Maynard Handley | 2020/07/19 10:47 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | anon2 | 2020/07/19 03:24 PM |
VLIW, OOO, Pairing, and Fusion | Chester | 2020/07/19 10:16 PM |
Poulson was in-order (NT) | anon2 | 2020/07/20 12:20 AM |
VLIW, OOO, Pairing, and Fusion | Michael S | 2020/07/20 12:48 AM |
Itanium is NOT VLIW | Heikki Kultala | 2020/07/20 02:27 PM |
Itanium is NOT VLIW | Adrian | 2020/07/20 11:03 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Heikki Kultala | 2020/07/21 03:38 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | anon2 | 2020/07/21 05:03 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | dmcq | 2020/07/21 03:27 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | j | 2020/07/21 08:54 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Tim McCaffrey | 2020/07/21 10:30 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Linus Torvalds | 2020/07/21 09:13 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 12:31 PM |
Turn that on its head? | Ray | 2020/07/22 12:49 PM |
Turn that on its head? | Anon | 2020/07/22 01:53 PM |
Turn that on its head? | Maynard Handley | 2020/07/22 02:37 PM |
Turn that on its head? | anon2 | 2020/07/22 03:32 PM |
Turn that on its head? | anon3 | 2020/07/22 04:45 PM |
Turn that on its head? | Heikki Kultala | 2020/07/23 02:53 AM |
Turn that on its head? | Anon | 2020/07/23 10:20 AM |
Turn that on its head? | Heikki Kultala | 2020/07/23 11:21 AM |
Turn that on its head? | Brett | 2020/07/23 03:26 PM |
Turn that on its head? | Brett | 2020/07/24 04:22 AM |
Bundling OOO entries does this implicitly | David Kanter | 2020/07/23 10:56 AM |
Turn that on its head? | anon | 2020/07/23 11:49 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Maynard Handley | 2020/07/22 02:29 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/22 03:16 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Doug S | 2020/07/22 10:37 PM |
what Intel would have done | Michael S | 2020/07/23 12:46 AM |
what Intel would have done | Doug S | 2020/07/23 09:52 AM |
what Intel would have done | Anon | 2020/07/23 10:25 AM |
what Intel would have done | Michael S | 2020/07/23 11:23 AM |
what Intel would have done | Montaray Jack | 2020/07/23 06:08 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 11:47 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/23 01:46 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Michael S | 2020/07/23 12:56 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/23 02:44 AM |
thanks | Chester | 2020/07/24 03:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 07:46 PM |
Alder Lake and AVX-512 | never_released | 2020/07/11 08:54 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:25 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:36 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 12:01 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:41 AM |
Alder Lake and AVX-512 | rwessel | 2020/07/12 10:17 AM |
Alder Lake and AVX-512 | -.- | 2020/08/18 03:24 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/08/18 11:04 PM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 07:49 PM |
Alder Lake and AVX-512 | anon | 2020/07/11 08:12 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:00 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/12 08:51 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 10:30 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 07:43 AM |
Alder Lake and AVX-512 | Montaray Jack | 2020/07/23 07:20 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/24 04:57 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 11:35 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:15 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 01:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:31 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 03:09 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 04:25 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 08:34 PM |
Alder Lake and AVX-512 | Jose | 2020/07/13 01:35 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:11 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:01 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:06 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/13 12:11 PM |
Alder Lake and AVX-512 | Brett | 2020/07/14 02:34 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/14 09:02 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 12:40 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:48 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/15 01:37 AM |
OS X file names normalization | Michael S | 2020/07/15 02:26 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 04:16 AM |
OS X file names normalization | Michael S | 2020/07/15 10:51 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 12:27 PM |
OS X file names normalization | Doug S | 2020/07/15 10:46 AM |
OS X file names normalization | Michael S | 2020/07/15 11:05 AM |
OS X file names normalization | Linus Torvalds | 2020/07/15 12:58 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 02:21 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:57 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:44 PM |
OS X file names normalization | Rob Thorpe | 2020/07/15 11:23 AM |
OS X file names normalization | Doug S | 2020/07/15 01:32 PM |
OS X file names normalization | Maynard Handley | 2020/07/15 05:20 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 08:37 PM |
OS X file names normalization | Anon3 | 2020/07/16 01:43 PM |
OS X file names normalization | Doug S | 2020/07/16 03:38 PM |
OS X file names normalization | Linus Torvalds | 2020/07/17 12:21 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:15 AM |
OS X file names normalization | Jukka Larja | 2020/07/17 06:40 AM |
OS X file names normalization | gallier2 | 2020/07/17 03:19 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 09:41 AM |
OS X file names normalization | Dummond D. Slow | 2020/07/17 09:54 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 10:16 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/18 06:12 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:04 AM |
OS X file names normalization | Doug S | 2020/07/17 10:15 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/15 10:32 AM |
File Systems and VC Problems | Rob Thorpe | 2020/07/15 07:24 AM |
vectorization of utf8 | Robert David Graham | 2020/07/13 02:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 05:07 PM |
vectorization of utf8 | Robert David Graham | 2020/07/13 08:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 11:23 PM |
vectorization of utf8 | Maynard Handley | 2020/07/13 10:46 PM |
vectorization of utf8 | Gabriele Svelto | 2020/07/15 03:27 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/14 01:13 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 01:29 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:08 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 06:26 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 07:11 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 07:43 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 08:38 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 10:10 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 11:02 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:22 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 12:10 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 04:03 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/14 06:53 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 08:34 PM |
Alder Lake and AVX-512 | Brett | 2020/07/11 09:02 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/13 12:36 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/13 01:01 PM |
Alder Lake and AVX-512 | Brett | 2020/07/13 04:19 PM |
Alder Lake and AVX-512 | Geert | 2020/07/11 09:36 PM |
AMD's FPU | Chester | 2020/07/12 02:28 AM |
Is 3|5 lower than 4? | Michael S | 2020/07/12 03:59 AM |
Is 3|5 lower than 4? | Chester | 2020/07/12 05:54 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 11:45 PM |
Alder Lake and AVX-512 | me | 2020/07/12 03:44 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:09 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:35 AM |
~80% of details are wrong. So what one can expect from conclusions? :( (NT) | Michael S | 2020/07/12 11:57 AM |
~80% of details are wrong. So what one can expect from conclusions? :( | anonymous2 | 2020/07/12 12:50 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:25 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:37 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:43 PM |
Alder Lake and AVX-512 | me | 2020/07/12 01:32 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 08:51 PM |
Alder Lake and AVX-512 | UnmaskedUnderflow | 2020/07/12 12:33 PM |
AVX-512 vs SVE2 | -.- | 2020/07/12 06:22 PM |
AVX-512 vs SVE2 | noko | 2020/07/13 12:12 AM |
AVX-512 vs SVE2 | -.- | 2020/07/13 04:00 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/12 08:18 PM |
Could you please stop top-posting (NT) | Jukka Larja | 2020/07/13 08:45 AM |
Alder Lake and AVX-512 | Romain Dolbeau | 2020/07/15 01:00 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:59 AM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/13 09:12 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:21 PM |
Alder Lake and AVX-512 | Jouni Osmala | 2020/07/14 02:55 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:11 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:13 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:10 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 10:09 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 10:53 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:27 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Maynard Handley | 2020/07/14 12:52 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Doug S | 2020/07/14 01:43 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 03:01 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Linus Torvalds | 2020/07/14 12:00 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:42 PM |
Configurable cache line size? | Doug S | 2020/07/15 10:56 AM |
Configurable cache line size? | dmcq | 2020/07/15 03:43 PM |
Configurable cache line size? | Romain Dolbeau | 2020/07/15 11:37 PM |
Configurable cache line size? | NoSpammer | 2020/07/16 01:27 AM |
Configurable cache line size? | Pixie | 2020/07/16 10:55 AM |
Configurable cache line size? | Etienne | 2020/07/17 01:03 AM |
Configurable cache line size? | Hugo Décharnes | 2020/07/18 02:11 AM |
Cache line size | Mark Roulo | 2020/07/15 06:10 PM |
Cache line size | anon | 2020/07/15 06:46 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Gabriele Svelto | 2020/07/17 02:30 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | dmcq | 2020/07/17 03:34 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | zArchJon | 2020/07/17 01:16 PM |
Macro-instructions to the rescue | ⚛ | 2020/07/24 12:56 PM |
Some fundamentals haven't changed | Chester | 2020/07/24 03:59 PM |
Some fundamentals haven't changed | ⚛ | 2020/07/24 04:24 PM |
Some fundamentals haven't changed | dmcq | 2020/07/25 07:58 AM |
Some fundamentals haven't changed | ⚛ | 2020/07/25 11:05 AM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:16 PM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:27 PM |
What belt is. | Heikki Kultala | 2020/07/26 07:49 AM |
What belt is. | Michael S | 2020/07/26 10:00 AM |
What belt is. | Brett | 2020/07/26 11:46 PM |
What belt is. | Michael S | 2020/07/27 12:52 AM |
What belt is. | Brett | 2020/07/27 07:25 AM |
What belt is. | Doug S | 2020/07/27 01:31 PM |
What belt is. | Andrew Clough | 2020/07/28 06:11 AM |
What belt is. | dmcq | 2020/07/28 08:17 AM |
Mill Compiler still MIA? | Geoff Langdale | 2020/07/28 05:04 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust (NT) | Anon | 2020/07/28 05:20 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust | Anon | 2020/07/28 05:20 PM |
Apparently they're busy writing a kernel... | Anon | 2020/07/29 03:03 AM |
Apparently they're busy writing a kernel... | dmcq | 2020/07/29 03:39 AM |
What belt is. | ⚛ | 2020/07/26 11:44 AM |
What belt is. | anonymous2 | 2020/07/26 12:02 PM |
What belt is. | Doug S | 2020/07/26 03:26 PM |
What belt is. | ⚛ | 2020/07/26 04:02 PM |
good | useruser | 2020/07/12 10:06 AM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:03 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:07 PM |
Alder Lake and AVX-512 | j | 2020/07/13 12:29 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 01:12 AM |
Alder Lake and AVX-512 | j | 2020/07/13 02:58 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/13 04:53 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:57 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 10:26 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 12:33 PM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 03:43 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 12:55 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:19 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 02:34 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:03 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 09:43 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 09:54 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 11:35 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:18 PM |
GV100 + POWER9 | Michael S | 2020/07/16 01:17 AM |
GV100 + POWER9 | dmcq | 2020/07/16 08:58 AM |
GV100 + POWER9 | dmcq | 2020/07/16 09:10 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:48 AM |
Alder Lake and AVX-512 | o | 2020/07/12 03:08 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:07 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:32 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:39 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 12:47 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:18 PM |
x87 crap | Heikki Kultala | 2020/07/12 01:30 PM |
x87 crap | Michael S | 2020/07/12 01:37 PM |
x87 crap | Heikki kultala | 2020/07/12 02:11 PM |
x87 crap | Michael S | 2020/07/12 02:50 PM |
Sparc and PA-RISC vs pentium FP performance | Heikki Kultala | 2020/07/13 01:14 AM |
Sparc and PA-RISC vs pentium FP performance | anonymous2 | 2020/07/13 10:48 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 03:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:10 PM |
Alder Lake and AVX-512 | David Kanter | 2020/07/12 05:01 PM |
Alder Lake and AVX-512 | anon | 2020/07/12 05:40 PM |
~0% of users do much FP outside of GPUs for games (NT) | anonymous2 | 2020/07/12 05:47 PM |
~0% of users do much FP outside of GPUs for games | Maynard Handley | 2020/07/13 12:26 AM |
not true | Chester | 2020/07/13 12:37 AM |
not true | Michael S | 2020/07/13 01:29 AM |
not true | Chester | 2020/07/13 01:59 AM |
not true | anonymous2 | 2020/07/13 10:32 AM |
not true | Maynard Handley | 2020/07/13 02:30 PM |
not true | Chester | 2020/07/14 05:47 AM |
not true | Doug S | 2020/07/13 12:30 PM |
not true | Anon | 2020/07/13 01:16 PM |
not true | Maynard Handley | 2020/07/13 02:39 PM |
not true | Maynard Handley | 2020/07/13 02:38 PM |
not true | Linus Torvalds | 2020/07/13 11:27 AM |
not true | Dummond D. Slow | 2020/07/13 02:10 PM |
not true | Maynard Handley | 2020/07/13 02:49 PM |
not true | Dummond D. Slow | 2020/07/13 03:38 PM |
not true (about FP, not avx-512) | Chester | 2020/07/17 10:37 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 06:45 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 06:57 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 04:26 PM |