The link you provided might show that it's cheaper to build your own Mac than to buy one from Apple. However, since the same PC you built would run Windows, then it is necessarily the case that it cannot be less expensive to build a Mac; at best it costs the same.
Now the point that you are missing is that the Mac supports far less hardware than Windows supports. If there exists at least one component that is not supported by MacOS but is supported by Windows, and that component is cheaper than any comparable component suppored by MacOS, then it must be the case that it is cheaper to build a PC.
How did you manage to miss the entire point? And further, where did you learn logic and economics?
Getting denied access to a cost=1x device and instead being pointed to an inferior cost=10x device is not about the profit motive at all. It's about avoiding fraud. As a previous poster said, if Medicare actually approved iPhones for speech impairment, we would, overnight, see an epidemic of speech impediments in the US, orders of magnitude over what the base rate is now.
Now if Apple made an iPhone with app store, internet, voice, and iPod functionality disabled that could run this application only, then I suspect that Medicare would approve it. But Apple won't (because of the profit motive). Designing, building, and marketing devices is expensive. It's hard to bring a device to market that will only be bought and used by a small number of people, and such devices tend to be clunky (just good enough because elegant design is expensive and time consuming and you're already fighting expense) and expensive (because you can't take advantage of economies of scale). Government certification (because in the US, they often foot the bill) is also expensive.
Bad example. Comparing infant mortality rates between countries is not an apples-to-apples comparison; making such an assumption inaccurately assumes that we count the same way. We don't. In fact the way we count guarantees that we will have among the highest counts. http://health.usnews.com/usnews/health/articles/060924/2healy.htm
Infant mortality numbers do not indicate that the US health care system is in any way inferior to anyone else'. There may be compelling arguments to support such a proposition, but infant mortality is not one of them.
BTW why are we discussing this in a copyright thread?
NTFS reads blocks. If your hosts file is smaller than 1 block, it doesn't make a disk I/O difference HOW BIG each address is.
String parsing is fast. Perhaps it would be a reduction of a couple dozen CPU cycles to read a "0" rather than "127.0.0.1", but that actually might be offset if the code to look for 0 caused a page fault due to code bloat to support special cases. Under the covers Windows would still have to alloc a SOCKADDR so we're only talking about a difference in parsing complexity.
Plus, the AC poster obviously isn't familiar with Windows DNSClient service. It is not actually necessary to parse LMHOSTS every time a network connection is made by name; the file is only parsed when it changes.
(1) Encode the data as the packet length. (2) Encode the data as the packet checksum (3) Encode the data as the fragment offset. (4) Encode the data as the number of extra ACKS. (5) Encode the data as the starting connection sequence number. (6) Encode the data as the window size. (7) Encode the data as the inter-packet delay.
None of these are better, as they will all be interfered with or blocked by NATs and inline IDS. The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.
The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.
Detecting retransmits can be done and statistical anomalies detected. However most router, proxy & firewall vendors will probably not want to save the extra state per-connection (last seq# transmitted + retransmit count) per active connection which is required to do the detection.
Nothing prevents the retransmit payload from being encrypted. However I suggest a more subtle strategy: copy the first X bytes of the original packet and then add encrypted payload. Anyone who happens to look at one of these packets will see the "garbled" message and assume it's a TCP stack bug on the transmitting host.
Won't work. If there is a policy mechanism to "always allow" (e.g. "don't annoy me any more for this program"), then clever software developers will figure out how to to solve the "UAC Problem" _once_ in their setup routine (by pre-setting the policy), rather than fixing their programs to run as non-admin. Then they just use and adapt the same setup.exe for all their programs.
Then everyone is back to where we started- everything runs as admin.
I suspect that the Microsoft dev team considered that before they decided to annoy the shit out of their customers. One has to assume that they are neither stupid nor contemptuous of the people who pay their bills...
There is a process to put a driver in the box with Windows, thousands of devices do so. The RAZR didn't exist when Windows XP shipped and Motorola hasn't seen fit to either identify the device over USB generically (so an in-box driver would be used) or gone through the WHQL process to put their driver on Windows Update (for example, by providing driver verifier results to Microsoft to demonstrate a minimum quality bar) so that it would be automatically downloaded and installed when you first plugged in the phone.
Microsoft provided a way for Motorola to solve this problem for customers; Motorola made the choice not to do so. It's not Microsoft's problem or fault.
If the attackers knew it was a dry run, then they would not exhibit the signs of stress that the machine detects, therefore all would test negative.
If the attackers did NOT know it was a dry run, then they must also carry attack devices with them through the screening process, and be at risk of detection of the devices or by an observant screener or secondary screening.
Plus, they must either carry out the attack, making their future use moot, or have the attack called off at the last moment, which potentially subjects the organizers to risk of capture.
There are certainly other reasons to criticize the effort, but dry run attacks are not one of them.
After all, if the idea is to render authority-signed certs unnecessary, wouldn't you expect servers to abandon them as they expire, replacing them with self-signed certs? Is that going to be flagged as risky?
Why wouldn't the web site use their existing private key to perform an authenticated update the notary's records shortly before expiration, or issue themselves a new certificate using the same private key, etc., rather than generating a new private key and a new certificate?
In this case the web site would use their existing identity to bootstrap their new one. This is how renewal works in the hierarchical CA world.
If you want good logging, then define requirements for it, just as you would for any other feature of the program. You also need to define the audience for the log. The comments thread has focused on debug logging for developers (Linus "no debuggers" Torvalds would be proud) but there are a number of reasons why the users who are stuck^h^h^h blessed with your software might want logging. For instance:
- audit trails (often required by organizational security requirements or regulatory requirements) - accounting/billing (you'd be amazed at the odd ways people come up with to bill for things) - health monitoring (the admin might not want to watch your program 24x7 to see if it is running; they might want to program automation to be alerted when it is not working properly) - troubleshooting (believe it or not, your software might actually break when running in the wild)
Anyway, think about your use cases, and then think about what to instrument for each use case, and what to put in the events.
For instance, if you want to make your daemon monitorable for health, then think about all its dependencies. Does it read config from a file? The file is a dependency. What happens if a value is invalid? Does it fail or use a default? If it fails, reading the value is a dependency. Need a network socket? Dependency. Connection to remote machine? Dependency (actually multiple- name resolution, network connectivity, authentication, app-level connectivity, etc.). After you've enumerated all your dependencies, then add instrumentation in your code to log events when the dependency is unsatisfied (==unhealthy/broken), and when it is satisfied (==healthy). Make sure to log BOTH states, so that the monitoring app can decide which state you are in. Make sure to log only once per state transition. In each event, try to put as much information about the situation as you can- why you are in the state ("the value foo from daemon-config was invalid"), status codes, etc.- give your user a fighting chance of being able to use your log to diagnose and resolve the issue.
If you want to instrument for audit, then I suggest reading the Orange Book or the Common Criteria documents for suggestions on what needs to be audited and what information to put in the events.
Logging to a database is generally a poor strategy. I see this over and over and cringe every time.
Databases generally increase the overhead of logging significantly, and they don't add significant value. Sure, you can "select * from... where...". But do you REALLY need this? Most of the time when you need something from the log you can just grep/error/ or something comparable.
Databases are great for reporting but are just unnecessary overhead for logging.
Web Applications are optimized for Rapid Application Development.
Yep. Nothing says "Rapid Application Development" quite like "C". Except maybe assembly. Maybe I will build an AssemblyScript engine for web pages. Yeah, that's the ticket. Forget all this low-level AJAX stuff.
Teenagers aren't intellectually dumb at all- they're very bright and in fact many of them have greater mental agility, IQ point for IQ point, than those of us a generation older. But they are *NOT* the same as adults.
But what they lack is perspective, judgment, experience, and a sense of the consequences of their actions. To wit: teens are 4 times as likely as other drivers to be involved in a motor vehicle accident. This lack of experience & judgment might be called "dumb" colloquially but in reality is simply a fact that in homo sapiens, the section of the brain that implements these functions- the pre-frontal cortex- tends to develop later on average. Again, individual cases vary. And before you make the argument that we should treat everyone on a case by case basis; I would point out that with publicly-funded institutions like schools and courts we simply don't have the resources, nor necessarily do most families want that kind of uncertainty. For teens in exceptional circumstances there is emancipation.
The cases you describe- self sufficient teens- are pretty rare. The anecdotes you cite hint at selection bias. There certainly are many cases of extraordinary teens, either mature beyond their years or possessing skills that would make adults envious. But these are interesting precisely because they deviate from the norm.
Adults are often too hard on teenagers and (as a parent of a 16yo son) I can say that it is difficult to balance issues of power and authority in your interpersonal relationship with your child, with the child's need to develop into a self-sufficient independent adult. For instance, I own a house; it doesn't matter that my son has "his" room; he may not do "anything he wants" with it as it affects the value of my considerable real estate investment. He intellectually is capable of understanding this but his actions show either a lack of understanding of consequences or a lack of caring for the consequences. This is, I understand, typical for a teen, but can be a source of friction as I have to enforce rules such as "clean up after yourself" that he finds oppressive. He feels that he should have sovereignty over a piece of the house that I own, but even his recent history (last two weeks) indicates that he is unable to follow that simple house rule, so he's subject to periodic quick inspections, with lots of advance notice, which he still feels are invasions of his space.
In the online space we have a growing number of teens (and adults) who are unaware (or just don't care) that their "free speech" causes real harm. Adults don't get to say whatever they want; if teens want to be treated as adults and given adult rights then they must accept that responsibilities are concomitant. As an aside, I am sick of people of all ages whining about their right to free speech as justification for the most outrageous behavior- slander/libel, posting people's addresses online to invite harassment or violence, etc. Free speech is not an absolute as the Supreme Court has ruled numerous times, and saying stupid, mean or illegal things has consequences, whether they are legal or social. In many ways the internet is the worst possible place to say irresponsible things because it has such a long memory, but then again we are talking about teens and I am asserting that, on average, teens lack the judgment of adults.
Apple does not listen to their users. In fact Apple seems to hold their users in utter contempt, periodically breaking backwards compatiblity in massive ways, etc.
Can the "Microsoft Big Evil", "Apple Little Good" crap.
The report is a biased piece of crap. "Apple"=="commodity" is just bs trying to disguise that at its core this is all about siezing intellectual property from Microsoft.
If you want to target MSFT business practices such as OEM licensing, that's fine. If the EU wants to say "any OS that will be used by governments in the EU will have these characteristics...", that's fine too- as long as it applies to everyone. But singling out specific companies and not allowing them to compete in the same manner as their competitors, is just the worst sort of governmental corruption and is antithetical to a free society.
There are two things that people need to understand about monopolies and antitrust law.
First, the only monopolies that have the power to harm consumers in the long term (i.e. are immune to market forces) are government-created ones. A natural monopoly such as Microsoft exists primarily because consumers see the value in it. Sure, the behavior of the company can act to perpetuate it, but the company cannot be unresponsive to consumers precisely because there is nothing preventing them from pursuing other solutions. Yes, switching might be painful but MSFT would lose that customer forever, and will therefore will work hard to give customers reasons to stay other than "you're trapped". And Microsoft products are generally good.
Second, antitrust law is just a legal excuse to apply law unevenly and is a horrible standard for democracies to set- it means that at some arbitrary point, when politics turn against you, the rules change for you (and only you). What if government passed an "shared success" law, so that "successful" people got a higher tax rate? And it was up to the government to determine who was "successful"- but we won't have rules; it will be at the auditor's discretion. That's what antitrust law is all about. Ayn Rand got this one right.
If the EU truly believes consumers are being harmed, then the right thing to do is to set objective standards (open protocols, document formats, etc.) and then let the market respond. The *wrong* thing to do is to single out one company.
Slashdot Mirror
A good old wired POTS phone will work even if the power is out at your house. No UPS necessary.
Which is a free download from Microsoft:
http://msdn.microsoft.com/en-us/windows/bb980924.aspx?wt.svl=more_downloads
Actually, it has been shown to be cheaper to build your own Mac.
Your comment is a non sequitur.
The link you provided might show that it's cheaper to build your own Mac than to buy one from Apple. However, since the same PC you built would run Windows, then it is necessarily the case that it cannot be less expensive to build a Mac; at best it costs the same.
Now the point that you are missing is that the Mac supports far less hardware than Windows supports. If there exists at least one component that is not supported by MacOS but is supported by Windows, and that component is cheaper than any comparable component suppored by MacOS, then it must be the case that it is cheaper to build a PC.
slashdot needs some new editors who has a little common sense of the things they are publishing.
HAHAHAHAHahahaha.... oh wait, you were serious.
How did you manage to miss the entire point? And further, where did you learn logic and economics?
Getting denied access to a cost=1x device and instead being pointed to an inferior cost=10x device is not about the profit motive at all. It's about avoiding fraud. As a previous poster said, if Medicare actually approved iPhones for speech impairment, we would, overnight, see an epidemic of speech impediments in the US, orders of magnitude over what the base rate is now.
Now if Apple made an iPhone with app store, internet, voice, and iPod functionality disabled that could run this application only, then I suspect that Medicare would approve it. But Apple won't (because of the profit motive). Designing, building, and marketing devices is expensive. It's hard to bring a device to market that will only be bought and used by a small number of people, and such devices tend to be clunky (just good enough because elegant design is expensive and time consuming and you're already fighting expense) and expensive (because you can't take advantage of economies of scale). Government certification (because in the US, they often foot the bill) is also expensive.
Bad example. Comparing infant mortality rates between countries is not an apples-to-apples comparison; making such an assumption inaccurately assumes that we count the same way. We don't. In fact the way we count guarantees that we will have among the highest counts.
http://health.usnews.com/usnews/health/articles/060924/2healy.htm
Infant mortality numbers do not indicate that the US health care system is in any way inferior to anyone else'. There may be compelling arguments to support such a proposition, but infant mortality is not one of them.
BTW why are we discussing this in a copyright thread?
A far more serious issue will be sustained engineering - patches and so forth.
The AC is a retard.
NTFS reads blocks. If your hosts file is smaller than 1 block, it doesn't make a disk I/O difference HOW BIG each address is.
String parsing is fast. Perhaps it would be a reduction of a couple dozen CPU cycles to read a "0" rather than "127.0.0.1", but that actually might be offset if the code to look for 0 caused a page fault due to code bloat to support special cases. Under the covers Windows would still have to alloc a SOCKADDR so we're only talking about a difference in parsing complexity.
Plus, the AC poster obviously isn't familiar with Windows DNSClient service. It is not actually necessary to parse LMHOSTS every time a network connection is made by name; the file is only parsed when it changes.
Heh, I can think up a half dozen better stegas:
(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum
(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.
None of these are better, as they will all be interfered with or blocked by NATs and inline IDS. The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.
The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.
Detecting retransmits can be done and statistical anomalies detected. However most router, proxy & firewall vendors will probably not want to save the extra state per-connection (last seq# transmitted + retransmit count) per active connection which is required to do the detection.
Nothing prevents the retransmit payload from being encrypted. However I suggest a more subtle strategy: copy the first X bytes of the original packet and then add encrypted payload. Anyone who happens to look at one of these packets will see the "garbled" message and assume it's a TCP stack bug on the transmitting host.
Answer: not enough information
You need to stick to factual, well-defined questions; such as, "what is the air-speed velocity of an unladen swallow?"
OK I'll bite. African or European?
They should be doing this:
https://bugs.launchpad.net/ubuntu/+bug/156693
Won't work. If there is a policy mechanism to "always allow" (e.g. "don't annoy me any more for this program"), then clever software developers will figure out how to to solve the "UAC Problem" _once_ in their setup routine (by pre-setting the policy), rather than fixing their programs to run as non-admin. Then they just use and adapt the same setup.exe for all their programs.
Then everyone is back to where we started- everything runs as admin.
I suspect that the Microsoft dev team considered that before they decided to annoy the shit out of their customers. One has to assume that they are neither stupid nor contemptuous of the people who pay their bills...
There is a process to put a driver in the box with Windows, thousands of devices do so. The RAZR didn't exist when Windows XP shipped and Motorola hasn't seen fit to either identify the device over USB generically (so an in-box driver would be used) or gone through the WHQL process to put their driver on Windows Update (for example, by providing driver verifier results to Microsoft to demonstrate a minimum quality bar) so that it would be automatically downloaded and installed when you first plugged in the phone.
Microsoft provided a way for Motorola to solve this problem for customers; Motorola made the choice not to do so. It's not Microsoft's problem or fault.
A dry run would not work.
If the attackers knew it was a dry run, then they would not exhibit the signs of stress that the machine detects, therefore all would test negative.
If the attackers did NOT know it was a dry run, then they must also carry attack devices with them through the screening process, and be at risk of detection of the devices or by an observant screener or secondary screening.
Plus, they must either carry out the attack, making their future use moot, or have the attack called off at the last moment, which potentially subjects the organizers to risk of capture.
There are certainly other reasons to criticize the effort, but dry run attacks are not one of them.
After all, if the idea is to render authority-signed certs unnecessary, wouldn't you expect servers to abandon them as they expire, replacing them with self-signed certs? Is that going to be flagged as risky?
Why wouldn't the web site use their existing private key to perform an authenticated update the notary's records shortly before expiration, or issue themselves a new certificate using the same private key, etc., rather than generating a new private key and a new certificate?
In this case the web site would use their existing identity to bootstrap their new one. This is how renewal works in the hierarchical CA world.
+1 for parent.
If you want good logging, then define requirements for it, just as you would for any other feature of the program. You also need to define the audience for the log. The comments thread has focused on debug logging for developers (Linus "no debuggers" Torvalds would be proud) but there are a number of reasons why the users who are stuck^h^h^h blessed with your software might want logging. For instance:
- audit trails (often required by organizational security requirements or regulatory requirements)
- accounting/billing (you'd be amazed at the odd ways people come up with to bill for things)
- health monitoring (the admin might not want to watch your program 24x7 to see if it is running; they might want to program automation to be alerted when it is not working properly)
- troubleshooting (believe it or not, your software might actually break when running in the wild)
Anyway, think about your use cases, and then think about what to instrument for each use case, and what to put in the events.
For instance, if you want to make your daemon monitorable for health, then think about all its dependencies. Does it read config from a file? The file is a dependency. What happens if a value is invalid? Does it fail or use a default? If it fails, reading the value is a dependency. Need a network socket? Dependency. Connection to remote machine? Dependency (actually multiple- name resolution, network connectivity, authentication, app-level connectivity, etc.). After you've enumerated all your dependencies, then add instrumentation in your code to log events when the dependency is unsatisfied (==unhealthy/broken), and when it is satisfied (==healthy). Make sure to log BOTH states, so that the monitoring app can decide which state you are in. Make sure to log only once per state transition. In each event, try to put as much information about the situation as you can- why you are in the state ("the value foo from daemon-config was invalid"), status codes, etc.- give your user a fighting chance of being able to use your log to diagnose and resolve the issue.
If you want to instrument for audit, then I suggest reading the Orange Book or the Common Criteria documents for suggestions on what needs to be audited and what information to put in the events.
For accounting, examine the RADIUS RFCs.
Hope this helps.
Logging to a database is generally a poor strategy. I see this over and over and cringe every time.
Databases generally increase the overhead of logging significantly, and they don't add significant value. Sure, you can "select * from ... where ...". But do you REALLY need this? Most of the time when you need something from the log you can just grep /error/ or something comparable.
Databases are great for reporting but are just unnecessary overhead for logging.
Web Applications are optimized for Rapid Application Development.
Yep. Nothing says "Rapid Application Development" quite like "C". Except maybe assembly. Maybe I will build an AssemblyScript engine for web pages. Yeah, that's the ticket. Forget all this low-level AJAX stuff.
But what they lack is perspective, judgment, experience, and a sense of the consequences of their actions. To wit: teens are 4 times as likely as other drivers to be involved in a motor vehicle accident. This lack of experience & judgment might be called "dumb" colloquially but in reality is simply a fact that in homo sapiens, the section of the brain that implements these functions- the pre-frontal cortex- tends to develop later on average. Again, individual cases vary. And before you make the argument that we should treat everyone on a case by case basis; I would point out that with publicly-funded institutions like schools and courts we simply don't have the resources, nor necessarily do most families want that kind of uncertainty. For teens in exceptional circumstances there is emancipation.
The cases you describe- self sufficient teens- are pretty rare. The anecdotes you cite hint at selection bias. There certainly are many cases of extraordinary teens, either mature beyond their years or possessing skills that would make adults envious. But these are interesting precisely because they deviate from the norm.
Adults are often too hard on teenagers and (as a parent of a 16yo son) I can say that it is difficult to balance issues of power and authority in your interpersonal relationship with your child, with the child's need to develop into a self-sufficient independent adult. For instance, I own a house; it doesn't matter that my son has "his" room; he may not do "anything he wants" with it as it affects the value of my considerable real estate investment. He intellectually is capable of understanding this but his actions show either a lack of understanding of consequences or a lack of caring for the consequences. This is, I understand, typical for a teen, but can be a source of friction as I have to enforce rules such as "clean up after yourself" that he finds oppressive. He feels that he should have sovereignty over a piece of the house that I own, but even his recent history (last two weeks) indicates that he is unable to follow that simple house rule, so he's subject to periodic quick inspections, with lots of advance notice, which he still feels are invasions of his space.
In the online space we have a growing number of teens (and adults) who are unaware (or just don't care) that their "free speech" causes real harm. Adults don't get to say whatever they want; if teens want to be treated as adults and given adult rights then they must accept that responsibilities are concomitant. As an aside, I am sick of people of all ages whining about their right to free speech as justification for the most outrageous behavior- slander/libel, posting people's addresses online to invite harassment or violence, etc. Free speech is not an absolute as the Supreme Court has ruled numerous times, and saying stupid, mean or illegal things has consequences, whether they are legal or social. In many ways the internet is the worst possible place to say irresponsible things because it has such a long memory, but then again we are talking about teens and I am asserting that, on average, teens lack the judgment of adults.
If you don't work there anymore and you are telling the truth, why do you care if they know who you are?
Uhhh, Bullshit.
Apple does not listen to their users. In fact Apple seems to hold their users in utter contempt, periodically breaking backwards compatiblity in massive ways, etc.
Can the "Microsoft Big Evil", "Apple Little Good" crap.
Thank you.
I wish my coworkers would show some spontaneous brain activity.
I admit it. My Finnish is a little rusty.
And how, precisely, would you design a first person shooting game where the object was not to "kill the enemy before they fuck your shit up?"
Just curious.
The report is a biased piece of crap. "Apple"=="commodity" is just bs trying to disguise that at its core this is all about siezing intellectual property from Microsoft.
If you want to target MSFT business practices such as OEM licensing, that's fine. If the EU wants to say "any OS that will be used by governments in the EU will have these characteristics...", that's fine too- as long as it applies to everyone. But singling out specific companies and not allowing them to compete in the same manner as their competitors, is just the worst sort of governmental corruption and is antithetical to a free society.
There are two things that people need to understand about monopolies and antitrust law.
First, the only monopolies that have the power to harm consumers in the long term (i.e. are immune to market forces) are government-created ones. A natural monopoly such as Microsoft exists primarily because consumers see the value in it. Sure, the behavior of the company can act to perpetuate it, but the company cannot be unresponsive to consumers precisely because there is nothing preventing them from pursuing other solutions. Yes, switching might be painful but MSFT would lose that customer forever, and will therefore will work hard to give customers reasons to stay other than "you're trapped". And Microsoft products are generally good.
Second, antitrust law is just a legal excuse to apply law unevenly and is a horrible standard for democracies to set- it means that at some arbitrary point, when politics turn against you, the rules change for you (and only you). What if government passed an "shared success" law, so that "successful" people got a higher tax rate? And it was up to the government to determine who was "successful"- but we won't have rules; it will be at the auditor's discretion. That's what antitrust law is all about. Ayn Rand got this one right.
If the EU truly believes consumers are being harmed, then the right thing to do is to set objective standards (open protocols, document formats, etc.) and then let the market respond. The *wrong* thing to do is to single out one company.