If I have to choose I would prefer China spying on me than the US. China doesn't care wether I download movies and music, or if I want to smoke something else than tobacco.
Re:Does El Capitan Fix Major Problems?
on
WWDC 2015 Roundup
·
· Score: 1
Well, yes. An operating system does require a computer. I'm not sure what else you would expect.
OS X, unless you're willing to violate the license and whip up a Hackintosh, requires a computer from Apple. Linux doesn't, so, unlike OS X, it's less likely require you to buy a new computer in order to be able to use it.
Re:Does El Capitan Fix Major Problems?
on
WWDC 2015 Roundup
·
· Score: 1
The file dialog needs some love, or a setting that says "do not poll all disks" - I have an SSD as the boot drive, but I do have connected external and internal storage on spinning drives that is accessed infrequently.
It's a pain in the ass when you open a file dialog box and the system pauses to wait for all the drives to spin up. I would prefer it to only spin the drive up if I click on a folder or volume that is on that drive.
Code that thinks it's cheap to look at all volumes needs to be introduced to reality. Spinning disks up isn't even the worst case; think about attempting to contact a remote volume mounted from a slow server, or a server on a slow network, or a disconnected server.
The binary blobs are themselves dangerous - driver software is typically running with very high security clearance, and you have absolutely NO idea what is going on inside those blobs.
GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done.
and of the DMC firmware:
DMC provides additional graphics low-power idle states. It provides capability to save and restore display registers across these low-power states independently from the OS/Kernel.
The first of those sounds as if it runs on the graphics processor - the host submits work to the GPU, and it schedules the work to be done. The latter of those sounds as if it might run on the graphics processor as well, saving and restoring the display registers from within the GPU.
So this might not be running in the driver at all; the driver might just be loading that firmware into the GPU.
If you will kindly let me know what additional modules I need to install in my universal translator, I will be able to understand you better. Thank you.
The Markovian module (although, by comparison to Mr. Shaney's posts, that was, well, rather broken Markovian; perhaps it was published by the Dissociated Press).
Because I run Linux on VMs when I'm trying to do platform-specific work (and, as a core developer for a library with rather a lot of platform-dependent - and platform-OS-version-dependent - code implementing those attempting-to-be-mostly-platform-independent APIs, there's a fair bit of that involved).
As a result, I want to spend as little time as possible dicking with the OS, leaving as much time as possible to actually adding new capabilities and fixing bugs. Ubuntu seems to do a good job of that; if you have another distribution to recommend for this, please do. Note that, whilst I haven't yet had to do any kernel work (other people fixed thekernel issues before I got around to building a kernel with my changes), I'd like a distribution where the process of building and installing a new kernel is as simple a process as possible. Fedora fails here. (In the OS on which I last did kernel work, it's pretty much
There are the Asha model Nokia phones which are intended for the Indian market but there are also other cheap featurephones like the 105, 120 etc. which are sold here in the UK from Amazon and other sources either SIM-free or locked to carriers as PAYG. They are branded Nokia and, I presume, built by them.
"Sold here in the UK" does not necessarily imply "not built in India". The current 105 is another fine Microsoft product. I suspect it's built by Nokia at the aforementioned Indian facility; if not, it's probably built by Microsoft at one of the factories that Nokia did sell them.
By this, do you mean "the corporation named Nokia manufactures, in addition to mobile telephony infrastructure equipment, mobile phones", or "there are mobile phones that happen to be sold by Nokia", or "the corporation named Nokia makes mobile phones that they sell"?
If the former, are you referring to the phones made by Nokia's Indian manufacturing facilities? Those were one of the parts of the Devices and Services business not sold to Microsoft, as part of the deal selling most of that business to Microsoft, due to them being "subject to an asset freeze by the Indian tax authorities as a result of ongoing tax proceedings"? If so, that press release says that Nokia will use them to "produce mobile devices for Microsoft", so that they're Nokia-made but not Nokia-sold. I.e., Nokia is just acting as a contract manufacturer for Microsoft here, so they make phones in the same sense that, say, Foxconn makes phones; it's not clear that they have a long-term interest in being in the featurephone business. (Yes, I am familiar with the term "featurephone".)
Aren't these the two Android holdouts? Who uses these things?
"Android holdouts" as in "not making Android phones"?
Ericsson doesn't make any phones. They used to, but put that into a joint venture with Sony, and that's now just Sony Mobile, who make Android phones. What they do make is infrastructure hardware for telephony, including mobile telephony.
Nokia doesn't make any phones, either. They used to, but they sold that to some company in the Seattle area, Microsomethingorother if I remember correctly. What they do make is infrastructure for mobile telephony.
The summary says "Nantero plans on creating gum sticks SSDs using DDR4 interfaces."
TFA says:
Nantero doesn't plan on producing its own NRAM drives, which will initially be marketed for purposes similar to solid-state drive (SSD) gum sticks or internal memory boards. But it will license its intellectual property to companies to develop their own product. Nantero's engineers are still in the process of creating chip designs for the memory wafers.
(emphasis mine), which is, err, umm, the exact opposite of "Nantero plans on creating gum sticks SSDs" (or even "Nantero plans on creating gum stick SSDs").
As for what's being fabbed:
"So those fabs have been and are indeed producing large numbers of wafers and chips," said Greg Schmergel, CEO of Nantero. "They are sample chips/test chips in preparation for mass production, which requires the product designs to be completed."
Schmergel said it will likely take a couple more years before NRAM drives begin rolling off production lines.
so, whilst this is better than "we've constructed a 4-bit chip in the lab and, yes, it does reliably store 4 bits of data", let's wait a couple of years before we get too excited.
There's no law that says they can't pad the variable length input to fixed length
I'm not sure you quite understand the problem, it's not the input length, it is the encoding of each of the characters. So are you suggesting turning all single-byte encoded characters into multi-byte encoding of some arbitrary maximum length? If you can already identify the problem at this level then you would just do that in the parser that is truncating the string.
It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.
There's a lot to know, and people might not be aware of all of it and all the issues involved.
...and "really smart" might actually be a handicap if it means "I'm smart, I know how to do this, it's easy!", and not bother to Read TheFineManual, whereas somebody less smart might find Unicode scary and actually bother to RTFM.
From that description it does sound like the string is still valid. However if the display is crashing on a certain sequence containing an ellipsis, I am not clear why you can't construct that string directly, rather than rely on the insertion of the ellipsis.
Yup.
It does sound like they maybe rely on "sanitizing" but of a far more complex scheme that I was aware of.
Not to me, unless by "sanitizing" you mean "shortening so it'll fit in Notification Center".
This is still wrong, maybe far worse, as they are detecting and rejecting patterns containing ellipsis and some other character
I've seen nothing to indicate that they're doing anything specific with ellipses, other than "sticking them in at the point of truncation to let the user know that the full message isn't being displayed".
About all I'd assume is that certain sequences of characters are not being handled correctly by some part of Core Text; perhaps it's assuming, explicitly or implicitly, that those sequences "can't happen" and, instead of drawing them, crashing, perhaps in an assert.
In this case their glyph layout should simply not crash on any possible arrangement of bytes or words in the incoming string.
Correct.
It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.
There's a lot to know, and people might not be aware of all of it and all the issues involved.
So you are saying "fix the library". I am saying "sanitize input for library".
Both work, but I would argue that sanitizing for the library is usually a lot less problems.
"Programming for international environments is hard, let's go shopping!"
I would argue that you have perhaps not considered all the possible problems and have thus perhaps miscounted the problems with "work around a broken library by transforming perfectly legitimate Unicode character sequences into sequences that might not represent what the person sending the message intended", that being the correct description of the second approach to this problem in the list above.
Yeah, correctly truncating a message that could be an arbitrary sequence of text in multiple languages with combining character sequences and bidirectional text isn't easy, but, well, if you want to be thought of as a company that makes stuff that "just works", you'd better figure out how to make that complicated process "just work".
Maybe iOS 8.3.1 needs to have a quick fix of some sort, but iOS 10, if not iOS 9, should fix the truncation code.
In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle.
Where has it been proven that the bug is the trashing of a UTF-8 sequence?
First of all, Apple tends to use UTF-16 in the higher-level frameworks, e.g. that's how CFString/NSString work internally.
Second of all, processing entire characters rather than bytes is something I suspect Apple got right fairly early in the process. I suspect the problem is either that 1) when truncating the message for display, they're not processing entire graphemes, they're processing entire characters or 2) they're not taking bidirectionality into account or 3) they're not handling a combination of both issues.
He's saying that thing you call with your newly minted mangled string shouldn't fail.
Which is one way to solve it.
There are multiple things here that should be fixed. That's one of them - the renderer shouldn't crash if handed a bad string, it should fail more softly, e.g. put in a REPLACEMENT CHARACTER for all bad sequences and, if possible, log the error in a way that indicates that routine XXX has handed a bad character sequence to it.
I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle).
And I would argue (all the way to the heat death of the universe) that, if you know that the thing you call mangles strings, and if it's produced by somebody else working on the same OS, you get it fixed so that it doesn't do that; you don't mangle user input (which includes text messages from other users) in released software, unless you don't have time to fix the underlying problem for the release.
It's a bad character if the library you call will fuck it up. That's what makes it bad.
If it's a valid character in the character set being used, and a valid representation of the character in the encoding being used for that character set, then it is by definition not a bad character; if the library you call fucks it up, the library is bad.
The fuckup isn't the lack of "sanitization" of perfectly clean strings, the fuckup is the library's inability to handle those strings.
Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!
Then the fuckup is the overwriting of part of that character - or the overwriting of a combining character following a base character, or not handling bi-directionality correctly when figuring out where to and how to truncate the string. No, the rendering code shouldn't crash when handed the fucked-up string, but it should report the underlying bug somehow (in a way that gets back to the developer), so that bug doesn't go completely unnoticed.
(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)
...and, of course, when you're figuring out where to truncate, remember that some characters go right-to-left, not left-to-right - the string has both Roman-alphabet (left-to-right) and Arabic-alphabet (right-to-left) characters.
No you don't. You are demonstrating the typical moronic attempts to deal with UTF-8.
Here is how you do it:
Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there.
As long as you're not splitting a sequence of multiple characters (multiple characters, some of which might be encoded in multiple bytes with UTF-8) some of which are combining characters. Don't split a character from a combining character following it. Splitting a sequence like that can introduce more rendering errors into the string than are already there.
(I suspect that's what the problem is in this bug, given that there are several combining characters in the string as shown in various places.)
(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)
Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.
This is almost certainly due to splitting multibyte characters on sub-character boundaries.
Or mishandling combining characters; the screenshot geminidomino provided shows several combining characters, as indicated by the dotted-line circles in some of the glyphs (and I suspect some of the marks above the Arabic characters come from combining characters as well).
Slashdot Mirror
Not everything is about the NSA all the time.
Yes, sometimes it's about 3D printing instead.
If I have to choose I would prefer China spying on me than the US. China doesn't care wether I download movies and music, or if I want to smoke something else than tobacco.
It appears that China does care if you want to smoke at least one certain non-tobacco plant in China, at least.
Well, yes. An operating system does require a computer. I'm not sure what else you would expect.
OS X, unless you're willing to violate the license and whip up a Hackintosh, requires a computer from Apple. Linux doesn't, so, unlike OS X, it's less likely require you to buy a new computer in order to be able to use it.
The file dialog needs some love, or a setting that says "do not poll all disks" - I have an SSD as the boot drive, but I do have connected external and internal storage on spinning drives that is accessed infrequently.
It's a pain in the ass when you open a file dialog box and the system pauses to wait for all the drives to spin up. I would prefer it to only spin the drive up if I click on a folder or volume that is on that drive.
Code that thinks it's cheap to look at all volumes needs to be introduced to reality. Spinning disks up isn't even the worst case; think about attempting to contact a remote volume mounted from a slow server, or a server on a slow network, or a disconnected server.
You're thinking of the wrong school. Mass murderers have daddy buy their way into being a C student at Yale.
Al Gore or John Kerry?
Not Al Gore, given that he went to Harvard, not Yale.
The binary blobs are themselves dangerous - driver software is typically running with very high security clearance, and you have absolutely NO idea what is going on inside those blobs.
Well, on thing that might not be going on inside those blobs is "running on the CPU". The Intel download page for the firmware says of the GuC firmware:
and of the DMC firmware:
The first of those sounds as if it runs on the graphics processor - the host submits work to the GPU, and it schedules the work to be done. The latter of those sounds as if it might run on the graphics processor as well, saving and restoring the display registers from within the GPU.
So this might not be running in the driver at all; the driver might just be loading that firmware into the GPU.
If you will kindly let me know what additional modules I need to install in my universal translator, I will be able to understand you better. Thank you.
The Markovian module (although, by comparison to Mr. Shaney's posts, that was, well, rather broken Markovian; perhaps it was published by the Dissociated Press).
You cross 9 roads and come through unharmed.
So you think about the tenth like "it's just another road... I crossed others before and nothing happened".
But this one is different: this is the one that will kill you.
And this is the binary blob that will spy on you. If you can prove it's not, JUST DO IT.
Can you prove that the microcode running in the GPU isn't a binary-blob-in-Flash that will spy on you? What makes these binary blobs special?
Honest question. I want to know.
Because I run Linux on VMs when I'm trying to do platform-specific work (and, as a core developer for a library with rather a lot of platform-dependent - and platform-OS-version-dependent - code implementing those attempting-to-be-mostly-platform-independent APIs, there's a fair bit of that involved).
As a result, I want to spend as little time as possible dicking with the OS, leaving as much time as possible to actually adding new capabilities and fixing bugs. Ubuntu seems to do a good job of that; if you have another distribution to recommend for this, please do. Note that, whilst I haven't yet had to do any kernel work (other people fixed the kernel issues before I got around to building a kernel with my changes), I'd like a distribution where the process of building and installing a new kernel is as simple a process as possible. Fedora fails here. (In the OS on which I last did kernel work, it's pretty much
and it was, as I remember, similarly simple in the previous UN*X on which I did kernel work.)
There are the Asha model Nokia phones which are intended for the Indian market but there are also other cheap featurephones like the 105, 120 etc. which are sold here in the UK from Amazon and other sources either SIM-free or locked to carriers as PAYG. They are branded Nokia and, I presume, built by them.
"Sold here in the UK" does not necessarily imply "not built in India". The current 105 is another fine Microsoft product. I suspect it's built by Nokia at the aforementioned Indian facility; if not, it's probably built by Microsoft at one of the factories that Nokia did sell them.
Nokia do make mobile phones.
By this, do you mean "the corporation named Nokia manufactures, in addition to mobile telephony infrastructure equipment, mobile phones", or "there are mobile phones that happen to be sold by Nokia", or "the corporation named Nokia makes mobile phones that they sell"?
If the former, are you referring to the phones made by Nokia's Indian manufacturing facilities? Those were one of the parts of the Devices and Services business not sold to Microsoft, as part of the deal selling most of that business to Microsoft, due to them being "subject to an asset freeze by the Indian tax authorities as a result of ongoing tax proceedings"? If so, that press release says that Nokia will use them to "produce mobile devices for Microsoft", so that they're Nokia-made but not Nokia-sold. I.e., Nokia is just acting as a contract manufacturer for Microsoft here, so they make phones in the same sense that, say, Foxconn makes phones; it's not clear that they have a long-term interest in being in the featurephone business. (Yes, I am familiar with the term "featurephone".)
Microsoft appear, at least for the short term, to still be interested in making featurephones, so, if, as, and when the tax issues are resolved, Nokia may sell the Indian facilities to Microsoft as well, finishing the job of getting rid of their mobile phone handset business.
Aren't these the two Android holdouts? Who uses these things?
"Android holdouts" as in "not making Android phones"?
Ericsson doesn't make any phones. They used to, but put that into a joint venture with Sony, and that's now just Sony Mobile, who make Android phones. What they do make is infrastructure hardware for telephony, including mobile telephony.
Nokia doesn't make any phones, either. They used to, but they sold that to some company in the Seattle area, Microsomethingorother if I remember correctly. What they do make is infrastructure for mobile telephony.
The summary says "Nantero plans on creating gum sticks SSDs using DDR4 interfaces."
TFA says:
(emphasis mine), which is, err, umm, the exact opposite of "Nantero plans on creating gum sticks SSDs" (or even "Nantero plans on creating gum stick SSDs").
As for what's being fabbed:
so, whilst this is better than "we've constructed a 4-bit chip in the lab and, yes, it does reliably store 4 bits of data", let's wait a couple of years before we get too excited.
A laser technique is used to herd the fermions
So ... do fermions most resemble cows, or cats? I'm confused.
Well, fermions are called that because they exhibit Fermi-Dirac statistics, so they're arguably more like cats than cows.
There's no law that says they can't pad the variable length input to fixed length
I'm not sure you quite understand the problem, it's not the input length, it is the encoding of each of the characters. So are you suggesting turning all single-byte encoded characters into multi-byte encoding of some arbitrary maximum length? If you can already identify the problem at this level then you would just do that in the parser that is truncating the string.
...and then make sure you're handling combining character sequences and bidirectional text correctly.
It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.
There's a lot to know, and people might not be aware of all of it and all the issues involved.
...and "really smart" might actually be a handicap if it means "I'm smart, I know how to do this, it's easy!", and not bother to Read The Fine Manual, whereas somebody less smart might find Unicode scary and actually bother to RTFM.
And since some characters have different lengths, even counting characters might not be good enough.
And some characters might not always have a length and the length of some characters isn't "how much do you move to the right", it's "how much do you move to the left", so truncating is tricky.
but is it Bernard, Judi, or Ralph?
Presumably you're deliberately excluding Robert.
From that description it does sound like the string is still valid. However if the display is crashing on a certain sequence containing an ellipsis, I am not clear why you can't construct that string directly, rather than rely on the insertion of the ellipsis.
Yup.
It does sound like they maybe rely on "sanitizing" but of a far more complex scheme that I was aware of.
Not to me, unless by "sanitizing" you mean "shortening so it'll fit in Notification Center".
This is still wrong, maybe far worse, as they are detecting and rejecting patterns containing ellipsis and some other character
I've seen nothing to indicate that they're doing anything specific with ellipses, other than "sticking them in at the point of truncation to let the user know that the full message isn't being displayed".
About all I'd assume is that certain sequences of characters are not being handled correctly by some part of Core Text; perhaps it's assuming, explicitly or implicitly, that those sequences "can't happen" and, instead of drawing them, crashing, perhaps in an assert.
In this case their glyph layout should simply not crash on any possible arrangement of bytes or words in the incoming string.
Correct.
It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.
There's a lot to know, and people might not be aware of all of it and all the issues involved.
So you are saying "fix the library". I am saying "sanitize input for library".
Both work, but I would argue that sanitizing for the library is usually a lot less problems.
"Programming for international environments is hard, let's go shopping!"
I would argue that you have perhaps not considered all the possible problems and have thus perhaps miscounted the problems with "work around a broken library by transforming perfectly legitimate Unicode character sequences into sequences that might not represent what the person sending the message intended", that being the correct description of the second approach to this problem in the list above.
Yeah, correctly truncating a message that could be an arbitrary sequence of text in multiple languages with combining character sequences and bidirectional text isn't easy, but, well, if you want to be thought of as a company that makes stuff that "just works", you'd better figure out how to make that complicated process "just work".
Maybe iOS 8.3.1 needs to have a quick fix of some sort, but iOS 10, if not iOS 9, should fix the truncation code.
In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle.
Where has it been proven that the bug is the trashing of a UTF-8 sequence?
First of all, Apple tends to use UTF-16 in the higher-level frameworks, e.g. that's how CFString/NSString work internally.
Second of all, processing entire characters rather than bytes is something I suspect Apple got right fairly early in the process. I suspect the problem is either that 1) when truncating the message for display, they're not processing entire graphemes, they're processing entire characters or 2) they're not taking bidirectionality into account or 3) they're not handling a combination of both issues.
He's saying that thing you call with your newly minted mangled string shouldn't fail.
Which is one way to solve it.
There are multiple things here that should be fixed. That's one of them - the renderer shouldn't crash if handed a bad string, it should fail more softly, e.g. put in a REPLACEMENT CHARACTER for all bad sequences and, if possible, log the error in a way that indicates that routine XXX has handed a bad character sequence to it.
I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle).
And I would argue (all the way to the heat death of the universe) that, if you know that the thing you call mangles strings, and if it's produced by somebody else working on the same OS, you get it fixed so that it doesn't do that; you don't mangle user input (which includes text messages from other users) in released software, unless you don't have time to fix the underlying problem for the release.
It's a bad character if the library you call will fuck it up. That's what makes it bad.
If it's a valid character in the character set being used, and a valid representation of the character in the encoding being used for that character set, then it is by definition not a bad character; if the library you call fucks it up, the library is bad.
The fuckup isn't the lack of "sanitization" of perfectly clean strings, the fuckup is the library's inability to handle those strings.
Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!
Then the fuckup is the overwriting of part of that character - or the overwriting of a combining character following a base character, or not handling bi-directionality correctly when figuring out where to and how to truncate the string. No, the rendering code shouldn't crash when handed the fucked-up string, but it should report the underlying bug somehow (in a way that gets back to the developer), so that bug doesn't go completely unnoticed.
(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)
...and, of course, when you're figuring out where to truncate, remember that some characters go right-to-left, not left-to-right - the string has both Roman-alphabet (left-to-right) and Arabic-alphabet (right-to-left) characters.
No you don't. You are demonstrating the typical moronic attempts to deal with UTF-8.
Here is how you do it:
Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there.
As long as you're not splitting a sequence of multiple characters (multiple characters, some of which might be encoded in multiple bytes with UTF-8) some of which are combining characters. Don't split a character from a combining character following it. Splitting a sequence like that can introduce more rendering errors into the string than are already there.
(I suspect that's what the problem is in this bug, given that there are several combining characters in the string as shown in various places.)
(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)
Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.
This is almost certainly due to splitting multibyte characters on sub-character boundaries.
Or mishandling combining characters; the screenshot geminidomino provided shows several combining characters, as indicated by the dotted-line circles in some of the glyphs (and I suspect some of the marks above the Arabic characters come from combining characters as well).