Much of that centimeter is taken up by the back, the screen, and the glass, and wherever there is no circuitry, the rest of the thickness is occupied by the battery, which would have to get much smaller to accommodate a component that takes up the full thickness of the interior compartment. I don't think "power would be an issue" quite covers it.
Also, if you have a hard drive, you almost certainly need a full metal frame for mounting purposes and, ideally, an air gap above and below it so that it doesn't get crushed and/or dig into the back side of the LCD panel upon a light impact. Either that or you would need a thicker, more rigid back. Maybe both. All in all, that translates to a lot more thickness than you might otherwise expect.
Perhaps, but when your false statement leads to the death of 100,000 people, 500,000... who knows... don't you think you should at least be *investigated* as to whether you knowingly lied or not?
I fully agree with you on that point. I strongly suspect that many of those folks involved did, in fact, lie. It is not an absolute given, though. They could merely have been grossly incompetent.
It is, in fact, accurate. A lie is a false statement told knowingly with intent to deceive. A false statement told unknowingly is merely a mistake. Repeating a particularly significant false statement without verifying its truthfulness is a big mistake, of course, and at a certain point, you might even conclude the person is guilty of willful ignorance, at which point it might arguably be considered a lie, but as a general rule, without the intent to deceive, a false statement is not a lie.
The potential for the vaccine-producing banana cross-pollen... oh, wait... bananas aren't growable from seed. Never mind. In pretty much any other plant, that would be a bad idea because you wouldn't want to get a dose of a vaccine every time you ate some random piece of food. But in bananas, because of the need to grow them from cultivars, that might actually not be too harmful a GM modification. Carry on.
I'm not talking about the living areas. That's what the prefabricated pods are for. I'm talking about a partially pressurized dome as a place to grow food. Tents don't conduct light, ergo, plants don't grow. With tents, your power requirements go through the roof, because you have to both artificially light and heat your greenhouse. With glass (or plexiglass), you can get away with heat, and maybe not even all that much of that. Solar panels produce less and less power over time; a greenhouse will continue to provide the same amount of light and heat essentially forever, assuming nothing damages it.
Oh, yeah. I forgot the most important part. You need the world's largest air pump. (To be more precise, you need several of them so that you'll have spares.) You're going to need to bring the pressure of that dome up to at least a tenth of an atmosphere using only the available air—about a 20:1 increase in pressure—or else the plants will wither and die.
More to the point, they would try to influence the preparation to ensure that by the time they get there, the colony would be almost self-sustaining already. There's no reason it can't be done. Drop a bunch of large modules with breathable air and CO2 scrubbers, and verify remotely that they are all functioning before you send people. Then drop enough spare parts to scrub the air for at least a few decades, along with enough non-perishable food to last a similar period of time. Then drop enough building materials to build a huge, sealed, glass habitat to serve as a greenhouse for plants. Then drop equipment needed to build it (think "electric crane"). Then drop bags and bags of dirt. Then drop crates of seeds. Then drop enough solar panels to cover the state of Rhode Island and enough wire to hook it all up. Then remotely control all the equipment to make sure everything is working correctly. Then send the people to put it together. By that time, you've launched a dozen or more unmanned missions over the course of a decade, so you're sure of the launch vehicle and the landing craft. You've provided enough materials to create a sustainable living space, and you've provided enough materials to survive until they finish creating that space.
It's designed to replace the 64G of flash storage used in existing tablets, so comparing the new product with the old one is not unreasonable.
Except that this isn't. It's a 2.5" laptop hard drive that's 5mm thick. In other words, they cut the thickness of a laptop hard drive to a little more than half their normal height and cut the capacity in half to match.
By my math, this hard drive takes up about 35 cubic centimeters of volume. A 128 GB SD card takes up about 1.6 cubic centimeters. All told, then, this is almost 22 times the size of a 128 GB flash card (including the packaging) and provides only about 4 times the capacity. So it's more like building something the size of the library of congress, but with only a little more than the capacity of a normal library.
Bottom line: this thing is huge. The only advantage over putting in lots more flash is that it is cheaper. In terms of space, it's a significant net loss, and I'm sure it is also worse than flash in terms of power consumption. This might be interesting as a way to make laptops thinner, but for tablets, it's just way too big, I think, unless tablet makers are willing to significantly increase the thickness of their devices.
The "feature" could be in the microcode for the CPU.
That's not realistically very likely. Microcode typically never gets updated after the CPU ships, which means that as soon as some critical part of the compiled binary looks slightly different, the microcode won't have the desired effect. It doesn't take a large compiler change to screw that sort of thing up. Even tiny optimization changes would prevent microcode from usefully changing the behavior of a particular binary. The microcode level is just way too low level.
Unless the "unrelated compiler" is also compromised. How far down does the rabbit hole go?
This is why you start by compiling a very simple, basic compiler like PCC using your choice of random, potentially compromised compiler, then use that PCC binary to compile a new copy of PCC. The resulting PCC-compiled PCC binary should be both small enough and simple enough instruction-wise for a few dozen people to feasibly audit it by hand. Use that to then build a verifiably source-clean copy of GCC. Use that, in turn, to build a source-clean copy of LLVM/Clang. And now you have a modern compiler that's almost certainly not generating dirty code.
First, that link isn't to the app store. That's the boxed edition. Second, you'll notice that in the product description for this feature, there's a ** that says "Separate purchase in the App Store".
So unless that page you linked to is lying, the App Store version does not do what they're talking about here. Only the separate installer that you get directly from Parallels installs the daemon in question.
That's one possible way to interpret that sentence, but only if you use the non-technical (particularly military) meaning of the word "compromise".
As a programmer, the way I would interpret that sentence is "The NSA cracked into a CA's systems or otherwise holds some technical ability to forge their certificates (e.g. key theft). In a technical context, the word compromise is usually limited to cases of coercion or attack. If you crack into my computer and run code to sign your app, you've compromised my computer. If you ask me to sign your app and I do so, you have not compromised my computer, though if your app is bad, you have compromised others' trust in my signing.
One should purchase a new copy of the Windows 8 for the said hard disk, and install this on the disk. This would effectively wipe clean the disk of any previous content.
I think you're on the right track. Installing a single copy of Windows 8 should fill pretty much any hard drive, thus completely overwriting any contents that might have been there before.
No need to compromise anything. They just need a single CA to be complicit with a court order to produce a certificate that signs an NSA-provided key for a specific site. Then, they can freely MITM that site. SSL is swiss cheese as security goes, because certs are automatically trusted if signed by a CA, are never stored, and their designated requirements are never checked when determining whether a new key should be trusted or not. In short, SSL is a train wreck.
Self-signed keys are not more secure. If a site goes from a self-signed cert to a signed cert with a different key, most browsers do not display any warning. Although you can install anti-MITM tools that produce a warning when the key changes, those tools would detect such a government MITM whether you're using a CA-signed cert or a self-signed cert. By contrast, a CA-signed cert makes it much harder to perform a MITM attack the first time a user goes to your site, effectively limiting such attacks to those who can convince a CA to give them a cert for your site. Guess which is more likely.
And yet, their data is mostly worthless. By the time I post about something on Facebook, 99% of the time, it is no longer actionable. For example, I'm seeing ads for hot water heaters because mine sprung a leak. That's not the sort of thing you put off fixing, so by the time I saw the first water heater ad on Facebook, the new water heater was already ordered and installed.
And they keep doing that over and over. I'll order something, and the next day they'll show me ads for similar products. Helpful hint: I just bought a cornet. I'm not likely to be interested in buying a second one. At least "You just bought [X], so you might like [accessories for X]" ads would be useful, but the "You just bought [X] so you might be interested in [slight variant of X]" ads are pretty much useless. Thus far, I've seen exactly one such ad that was even marginally plausible—an ad for camera lenses from some vintage products website after I bought a vintage lens on eBay. However, even that is not the sort of thing you buy every day. Show me that ad again in a year or two.
What makes the ads even more useless is that they're for the same type of product from companies that I already do business with. They aren't introducing me to new businesses. They aren't introducing me to new products that I'm not already aware of, having just studied that business's offerings in that area. So what exactly is the purpose of showing me this ad?
But the best part is that they keep showing me ads for products made by my employer's biggest competitor. They know who my employer is.
Yeah, I'm pretty sure their data mining strategy involves a drunken monkey flinging crap against the wall.
Fixing one more bug shouldn't radically change your UI design. With regards to your second point, I guess my point was that this shouldn't happen, and if it does, you're doing it wrong.;-)
On the one hand, this might be an argument for cloning the Wiki to a separate section when you do a major version branch.
On the other hand, this might also be an argument for why you need to design your user interface right the first time, so that users aren't completely befuddled when they encounter documentation for a newer version of the software (notwithstanding new features).
True, but my point is that you need both. The documentation of the code is orientation for people who intend to modify your software. User guides are documentation of the behavior of the software as a whole for people who merely intend to use the output of your code.
There's a difference between a tutorial and documentation? Who'd have thunk!
Actually, no there isn't. A tutorial is one type of documentation. Tutorials are documentation for processes. Non-process subjects require other approaches. It is important to write the right types of documentation based on the likely audience and the subject matter.
I disagree with many things in this article, not because the points are invalid, but because they conflate misuse of tools with low quality of tools. For example:
Wikis are great tools for writing documentation. They make it easy for people to fix minor errors when they notice them. They make it easy to collaborate on documentation without having to deal with the relatively high overhead of source code version control systems (which are particularly awful when merging structured content like XML and HTML).
What the author is complaining about is not the wiki, but rather the fact that those projects have no one who is responsible for maintaining the documentation. If no one is responsible for writing the docs and ensuring their completeness, the documentation will inevitably be half-finished, whether they use a wiki or some other mechanism. The wiki is not an alternative to writing documentation, but rather is a tool for creating documentation.
Doc generation software is great for writing reference documentation. By placing the content into the source code, it becomes the responsibility of the programmer to update any behavior changes when they modify the behavior of a function. It also means that the documentation for the function is easily readable right there in the source code when you're trying to understand a function. By producing the generated documentation, you then have a convenient reference for all your functions, methods, classes, data types, etc. that is readily searchable, indexable, and (perhaps most importantly) is viewed in a separate app or window from your source code so it doesn't force you out of your coding flow when you need to look something up.
Once again, what the author is complaining about is not the doc generation tool, but rather the fact that those projects have no one who is responsible for writing the documentation. When used properly, the output of doc generation tools is every bit as good as documentation produced by hand. However, it takes exactly as long to write that documentation in the source code as it does to write it in a word processor. It is not a tool for saving time, but rather a tool to aid in maintaining consistency between behavior and documentation.
To do software-generated documentation correctly, you need to add comments that explain every field in every data structure, every class, every function or method, and for particularly complex functions, even documentation for many of the local variables. You should write code in your build system to warn about undocumented methods and data structure fields. For example, in one project I regularly work on, there are almost 17,000 lines of documentation comments out of just shy of 59,000 total lines of code—a whopping 28.8% of the total code volume. The result is that it is fairly easy to learn what each piece does in the context of the code while you're looking at it, and the automatically generated documentation is pretty thoroughly fleshed out reference documentation for the project. One particularly complex class by itself produces a whopping 72 pages of reference documentation.
The problem that folks run into is that they usually don't put in any doc comments at all, or at best don't actually take the time to write the thorough comments that are needed to make the output from automatic reference documentation tools be useful. As a result, when you build the reference docs, you end up with an empty skeleton that isn't of much value at all. This is not a flaw in the tool; it is a flaw in the development team. They didn't take the time to write the documentation.
I'd really like to see libraries that loan out high-end electronic equipment. For example, I could easily see myself using a C500 occasionally, but not often enough to justify buying that instead of a RAV4....
That number is almost certainly crap. But to suggest that the number is zero is also crap. Thirty people died from acute radiation poisoning during the Chernobyl clean-up. You can say all you want to that "Nuclear accidents have not been proven to have killed a single person," but only if you can show a plausible way for them to have gotten acute radiation poisoning without it having been caused by the accident.
Slashdot Mirror
Much of that centimeter is taken up by the back, the screen, and the glass, and wherever there is no circuitry, the rest of the thickness is occupied by the battery, which would have to get much smaller to accommodate a component that takes up the full thickness of the interior compartment. I don't think "power would be an issue" quite covers it.
Also, if you have a hard drive, you almost certainly need a full metal frame for mounting purposes and, ideally, an air gap above and below it so that it doesn't get crushed and/or dig into the back side of the LCD panel upon a light impact. Either that or you would need a thicker, more rigid back. Maybe both. All in all, that translates to a lot more thickness than you might otherwise expect.
I fully agree with you on that point. I strongly suspect that many of those folks involved did, in fact, lie. It is not an absolute given, though. They could merely have been grossly incompetent.
It is, in fact, accurate. A lie is a false statement told knowingly with intent to deceive. A false statement told unknowingly is merely a mistake. Repeating a particularly significant false statement without verifying its truthfulness is a big mistake, of course, and at a certain point, you might even conclude the person is guilty of willful ignorance, at which point it might arguably be considered a lie, but as a general rule, without the intent to deceive, a false statement is not a lie.
The potential for the vaccine-producing banana cross-pollen... oh, wait... bananas aren't growable from seed. Never mind. In pretty much any other plant, that would be a bad idea because you wouldn't want to get a dose of a vaccine every time you ate some random piece of food. But in bananas, because of the need to grow them from cultivars, that might actually not be too harmful a GM modification. Carry on.
I'm not talking about the living areas. That's what the prefabricated pods are for. I'm talking about a partially pressurized dome as a place to grow food. Tents don't conduct light, ergo, plants don't grow. With tents, your power requirements go through the roof, because you have to both artificially light and heat your greenhouse. With glass (or plexiglass), you can get away with heat, and maybe not even all that much of that. Solar panels produce less and less power over time; a greenhouse will continue to provide the same amount of light and heat essentially forever, assuming nothing damages it.
Oh, yeah. I forgot the most important part. You need the world's largest air pump. (To be more precise, you need several of them so that you'll have spares.) You're going to need to bring the pressure of that dome up to at least a tenth of an atmosphere using only the available air—about a 20:1 increase in pressure—or else the plants will wither and die.
More to the point, they would try to influence the preparation to ensure that by the time they get there, the colony would be almost self-sustaining already. There's no reason it can't be done. Drop a bunch of large modules with breathable air and CO2 scrubbers, and verify remotely that they are all functioning before you send people. Then drop enough spare parts to scrub the air for at least a few decades, along with enough non-perishable food to last a similar period of time. Then drop enough building materials to build a huge, sealed, glass habitat to serve as a greenhouse for plants. Then drop equipment needed to build it (think "electric crane"). Then drop bags and bags of dirt. Then drop crates of seeds. Then drop enough solar panels to cover the state of Rhode Island and enough wire to hook it all up. Then remotely control all the equipment to make sure everything is working correctly. Then send the people to put it together. By that time, you've launched a dozen or more unmanned missions over the course of a decade, so you're sure of the launch vehicle and the landing craft. You've provided enough materials to create a sustainable living space, and you've provided enough materials to survive until they finish creating that space.
Except that this isn't. It's a 2.5" laptop hard drive that's 5mm thick. In other words, they cut the thickness of a laptop hard drive to a little more than half their normal height and cut the capacity in half to match.
By my math, this hard drive takes up about 35 cubic centimeters of volume. A 128 GB SD card takes up about 1.6 cubic centimeters. All told, then, this is almost 22 times the size of a 128 GB flash card (including the packaging) and provides only about 4 times the capacity. So it's more like building something the size of the library of congress, but with only a little more than the capacity of a normal library.
Bottom line: this thing is huge. The only advantage over putting in lots more flash is that it is cheaper. In terms of space, it's a significant net loss, and I'm sure it is also worse than flash in terms of power consumption. This might be interesting as a way to make laptops thinner, but for tablets, it's just way too big, I think, unless tablet makers are willing to significantly increase the thickness of their devices.
Oblig. xkcd: extrapolation
That's not realistically very likely. Microcode typically never gets updated after the CPU ships, which means that as soon as some critical part of the compiled binary looks slightly different, the microcode won't have the desired effect. It doesn't take a large compiler change to screw that sort of thing up. Even tiny optimization changes would prevent microcode from usefully changing the behavior of a particular binary. The microcode level is just way too low level.
This is why you start by compiling a very simple, basic compiler like PCC using your choice of random, potentially compromised compiler, then use that PCC binary to compile a new copy of PCC. The resulting PCC-compiled PCC binary should be both small enough and simple enough instruction-wise for a few dozen people to feasibly audit it by hand. Use that to then build a verifiably source-clean copy of GCC. Use that, in turn, to build a source-clean copy of LLVM/Clang. And now you have a modern compiler that's almost certainly not generating dirty code.
And the woman who backed into it?
Disaster.
Like the shoe? As in, "If someone throws his shoe on the rails, we'll have a nasty case of sabotage?"
First, that link isn't to the app store. That's the boxed edition. Second, you'll notice that in the product description for this feature, there's a ** that says "Separate purchase in the App Store".
So unless that page you linked to is lying, the App Store version does not do what they're talking about here. Only the separate installer that you get directly from Parallels installs the daemon in question.
That's one possible way to interpret that sentence, but only if you use the non-technical (particularly military) meaning of the word "compromise".
As a programmer, the way I would interpret that sentence is "The NSA cracked into a CA's systems or otherwise holds some technical ability to forge their certificates (e.g. key theft). In a technical context, the word compromise is usually limited to cases of coercion or attack. If you crack into my computer and run code to sign your app, you've compromised my computer. If you ask me to sign your app and I do so, you have not compromised my computer, though if your app is bad, you have compromised others' trust in my signing.
And by that, of course, you mean "Reporting pirated software saves IT jobs" ads from the BSA.
I think you're on the right track. Installing a single copy of Windows 8 should fill pretty much any hard drive, thus completely overwriting any contents that might have been there before.
No need to compromise anything. They just need a single CA to be complicit with a court order to produce a certificate that signs an NSA-provided key for a specific site. Then, they can freely MITM that site. SSL is swiss cheese as security goes, because certs are automatically trusted if signed by a CA, are never stored, and their designated requirements are never checked when determining whether a new key should be trusted or not. In short, SSL is a train wreck.
Self-signed keys are not more secure. If a site goes from a self-signed cert to a signed cert with a different key, most browsers do not display any warning. Although you can install anti-MITM tools that produce a warning when the key changes, those tools would detect such a government MITM whether you're using a CA-signed cert or a self-signed cert. By contrast, a CA-signed cert makes it much harder to perform a MITM attack the first time a user goes to your site, effectively limiting such attacks to those who can convince a CA to give them a cert for your site. Guess which is more likely.
And yet, their data is mostly worthless. By the time I post about something on Facebook, 99% of the time, it is no longer actionable. For example, I'm seeing ads for hot water heaters because mine sprung a leak. That's not the sort of thing you put off fixing, so by the time I saw the first water heater ad on Facebook, the new water heater was already ordered and installed.
And they keep doing that over and over. I'll order something, and the next day they'll show me ads for similar products. Helpful hint: I just bought a cornet. I'm not likely to be interested in buying a second one. At least "You just bought [X], so you might like [accessories for X]" ads would be useful, but the "You just bought [X] so you might be interested in [slight variant of X]" ads are pretty much useless. Thus far, I've seen exactly one such ad that was even marginally plausible—an ad for camera lenses from some vintage products website after I bought a vintage lens on eBay. However, even that is not the sort of thing you buy every day. Show me that ad again in a year or two.
What makes the ads even more useless is that they're for the same type of product from companies that I already do business with. They aren't introducing me to new businesses. They aren't introducing me to new products that I'm not already aware of, having just studied that business's offerings in that area. So what exactly is the purpose of showing me this ad?
But the best part is that they keep showing me ads for products made by my employer's biggest competitor. They know who my employer is.
Yeah, I'm pretty sure their data mining strategy involves a drunken monkey flinging crap against the wall.
Fixing one more bug shouldn't radically change your UI design. With regards to your second point, I guess my point was that this shouldn't happen, and if it does, you're doing it wrong. ;-)
Close. It actually says, "We apologize for the inconvenience."
On the one hand, this might be an argument for cloning the Wiki to a separate section when you do a major version branch.
On the other hand, this might also be an argument for why you need to design your user interface right the first time, so that users aren't completely befuddled when they encounter documentation for a newer version of the software (notwithstanding new features).
True, but my point is that you need both. The documentation of the code is orientation for people who intend to modify your software. User guides are documentation of the behavior of the software as a whole for people who merely intend to use the output of your code.
Actually, no there isn't. A tutorial is one type of documentation. Tutorials are documentation for processes. Non-process subjects require other approaches. It is important to write the right types of documentation based on the likely audience and the subject matter.
I disagree with many things in this article, not because the points are invalid, but because they conflate misuse of tools with low quality of tools. For example:
Wikis are great tools for writing documentation. They make it easy for people to fix minor errors when they notice them. They make it easy to collaborate on documentation without having to deal with the relatively high overhead of source code version control systems (which are particularly awful when merging structured content like XML and HTML).
What the author is complaining about is not the wiki, but rather the fact that those projects have no one who is responsible for maintaining the documentation. If no one is responsible for writing the docs and ensuring their completeness, the documentation will inevitably be half-finished, whether they use a wiki or some other mechanism. The wiki is not an alternative to writing documentation, but rather is a tool for creating documentation.
Doc generation software is great for writing reference documentation. By placing the content into the source code, it becomes the responsibility of the programmer to update any behavior changes when they modify the behavior of a function. It also means that the documentation for the function is easily readable right there in the source code when you're trying to understand a function. By producing the generated documentation, you then have a convenient reference for all your functions, methods, classes, data types, etc. that is readily searchable, indexable, and (perhaps most importantly) is viewed in a separate app or window from your source code so it doesn't force you out of your coding flow when you need to look something up.
Once again, what the author is complaining about is not the doc generation tool, but rather the fact that those projects have no one who is responsible for writing the documentation. When used properly, the output of doc generation tools is every bit as good as documentation produced by hand. However, it takes exactly as long to write that documentation in the source code as it does to write it in a word processor. It is not a tool for saving time, but rather a tool to aid in maintaining consistency between behavior and documentation.
To do software-generated documentation correctly, you need to add comments that explain every field in every data structure, every class, every function or method, and for particularly complex functions, even documentation for many of the local variables. You should write code in your build system to warn about undocumented methods and data structure fields. For example, in one project I regularly work on, there are almost 17,000 lines of documentation comments out of just shy of 59,000 total lines of code—a whopping 28.8% of the total code volume. The result is that it is fairly easy to learn what each piece does in the context of the code while you're looking at it, and the automatically generated documentation is pretty thoroughly fleshed out reference documentation for the project. One particularly complex class by itself produces a whopping 72 pages of reference documentation.
The problem that folks run into is that they usually don't put in any doc comments at all, or at best don't actually take the time to write the thorough comments that are needed to make the output from automatic reference documentation tools be useful. As a result, when you build the reference docs, you end up with an empty skeleton that isn't of much value at all. This is not a flaw in the tool; it is a flaw in the development team. They didn't take the time to write the documentation.
And so on.
I'd really like to see libraries that loan out high-end electronic equipment. For example, I could easily see myself using a C500 occasionally, but not often enough to justify buying that instead of a RAV4....
That number is almost certainly crap. But to suggest that the number is zero is also crap. Thirty people died from acute radiation poisoning during the Chernobyl clean-up. You can say all you want to that "Nuclear accidents have not been proven to have killed a single person," but only if you can show a plausible way for them to have gotten acute radiation poisoning without it having been caused by the accident.