I think you're closer than they are. My gut says it has more to do with the CNS nerves being encased in a hard shell (skull, spine) for their protection, and that this shell also puts an absolute limit on nerve growth beyond which additional growth would cause damage.
What his, and apparently your, thoughts about this don't take into account is that we may pass the typical number of fatalities on a single day as the body count rises from say, 28,000 to 42,000. In that hypothetical situation, you and that guy are ready to start caring. What are you going to do the next day when the count climbs from 42,000 to 60,000? At what point do you shit yourself? I watched a symposium on pandemic flu given by the NIH as part of my research, and I learned an interesting fact. During the 1918 Spanish flu outbreak, approximately 4,500 people died in the City of Philadelphia during the course of *one week*.
But the deaths started rolling in when the virus first hit Philadelphia, not after it had been bouncing around the community for months killing a tiny fraction of a percent of the people who got it. Growth of any illness is generally exponential based on contact, but death rate is generally linear in the number of infected. Therefore, if we're seeing a low death rate as a percentage of the population (and we are for H1N1), we will still see a low death rate as a percentage even if everyone got it. Judging from current stats, even if everyone in the U.S. got swine flu---every single man, woman, and child, based on current mortality figures, there would still be less than a factor of ten increase in deaths from the seasonal flu, and it is highly unlikely that we will see anywhere near a 100% infection rate.
Put another way, the chances of a virus mutating from killing single digit people to tens of thousands overnight are slim, and are probably equally likely whether you're talking about a mutation of H1N1 or of the common cold.
Yet you two don't want to do anything until the death toll passes the normal annual figure.
I think most of the folks saying "call me when it exceeds 36,000 deaths in a year" are really saying, "call me when the death toll is significantly higher than seasonal flu as a percentage of the infected or the percentage of exposed people who get infected is dramatically higher." In other words, "call me when the predicted annual death rate is expected to exceed 36,000 in a year." And that's a perfectly reasonable position.
No, the same total binary package size, twice the size for any given individual binary package. Of course, that's only a small percentage of the size of a typical OS distribution. ISTR that binaries are usually somewhere around 30% by volume. So if you add a second architecture, you've only added 30% to the size of the distro. You've also made it easier to ship one DVD instead of two, made it easier to create a single boot drive that works on a wider range of machines without sacrificing 64-bit or SSE3 on machines that support it, etc.
Because checking the architecture and choosing between a say x86 and x86_64 directory to copy the packages from is so complex, it's simply unbearable.
Because you get dependencies that can't be met because somebody forgot to compile one library for one architecture and that breaks something else, which breaks something else.... Or because somebody forgot to adjust that library path to install in a different directory for the 64-bit slice and the two binaries clobber one another.... Or because somebody screwed up and included one path in the Perl @INC path that corresponds with the opposite architecture and Perl throws a fit and fails to load a Perl module even though the one for the right architecture is there, just later in @INC.... Or because autoconf isn't smart enough to do the right thing in every case when the user needs to compile something. It's not just the installer complexity that's a problem. Having multiple library sets in different locations dramatically increases the complexity of almost everything on the system.
Windows supports fat binaries? Since when?
Since the COM file format, supported way to heck back in DOS.
What, you're going to release a distro cd made up entirely of FatELF binaries?
That's the idea, yes.
As far as I know, FatELF doesn't solve that either, so it's basically irrelevant in the context of this discussion. I could be wrong, though; how, exactly, would FatELF solve this better than separate compiled executables can solve it?
One library path for both architectures instead of two.
I guess that leads to another (genuine) question: under what circumstances would the majority of people be concerned about inode counts?
When they run out.:-D But seriously, reducing the number of files you create also significantly reduces install times even if you're writing the same amount of data. There's a non-negligible performance overhead in creating hundreds of thousands of extra files. And even if you only write out binaries for a single architecture, there's a non-zero performance hit to walking the larger directory trees on the install media, seeking farther because of the extra files from the architectures you skip, etc. Or you could ship separate DVDs, but then you're back to the user having to choose before they even get the OS up and running. And if they choose something that should work, but doesn't due to critical kernel bugs (been there, done that), then they get to download a whole separate ISO (and maybe even reinstall).
Point being, your "built-in" OS executables will only have one file anyway, since FatELF is redundant for them, meaning FatELF is only useful for third-party software.
Not at all. Take the case where there's a bug in a piece of software. In many cases, bugs behave differently or don't reproduce on all architectures. Thus, you may be able to work around the bug by running something in a different architecture. Also, third-party binaries are a great reason for having fat binaries, but they're nearly useless unless you also have fat libraries. As soon as you have built-in system libraries that are thin, you run a significant risk of having some libraries only installed for one architecture and not on another. This can easily turn the problem of choosing which slice to run into a case of the user having to manually run a particular slice, which is not a good user experience. That doesn't usually happen if you have all your system libraries built fat (unless somebody explicitly strips the libraries to a single architecture to save a few megs of disk space, in which case they deserve what they get).
Wrong -- you have half as many binary files. The number of packages can remain the same.
IIRC, at least the RPM format is single-architecture unless they've changed that recently. I can't comment on the other packaging formats. Single-architecture binary packages with multi-architecture docs/non-binary-files packages certainly did seem to be the most typical design pattern last time I checked, but then again, I've avoided building packages like the plague lately, so I could be behind the times.
Special linker, if it's there, is already done.
No, no it isn't. What's done is a colossal hack job in which everything gets built more than once, with different linker lines with different lib directories. And although I haven't created my own distro since that mess went in, I can tell just by looking at it that it is likely to be fragile and error-prone for the people who do. If I had to build a Linux distro now... well, I wouldn't build a Linux distro now. I think my reply would involve several swear words, followed by my resignation.:-D
Can you come up with a single example which isn't handled trivially by a script which selects the appropriate binary?
Speaking as somebody who beat my head against a wall dealing with cross-compilation in Linux for a while at my previous employer, are you sure you want to ask me that? Yeah. I can think of many examples where a script can't do it. We'll start with the easy one: Perl. Try to configure a multi-architecture version of Perl that way and ship it as part of an OS distro. I dare you. Building the binary is the easy part (and last I checked, it was still a total disaster involving hacking up the build script). After that, you now have to keep track of multiple trees full of binary modules, one per architecture, making sure that every one built correctly on every architecture, etc. With fat binaries, it becomes relatively easy. Each of those modules builds only ONCE, building each file several times, once per architecture. Each module either builds or it doesn't. The amount of overhead for the package maintainers is much, much less.
Oh, and remember that as soon as you get one app that does its own custom @INC hack to add a new directory full of Perl modules, you now get to hack up that Perl script to look in multiple places, depending on architecture. The problem can rapidly escalate for end users in a complex installation. Oh, and judging from history, they'd arbitrarily change the layout and the startup scripts every couple of releases, breaking all of those changes over and over. Versus a multi-architecture fat binary install where it stays in the same location, version number notwithstanding, and it doesn't matter what hardware you're running on. And since it's built into the kernel's binary format, people are much less likely to screw with it just because "It would be even better if we move this here and change this like that."
I suspect if I thought about it harder, I could come up with many more examples of problems you'd have just with Perl alone, not to mention other similarly complex kits (PHP, Ruby, etc.). They all pretty much have the same sorts of problems, and for the same reasons.
You either have the order of the codes or you don't. If you do, then anyone with access to that table can determine who someone voted for. If you don't, then the ballots can't be audited. So is this basically assuming that the Q table will never get leaked? *confused*
Okay, so you have a table with a list of what the valid options would be for a given ballot without giving the order. This still leaves open to the possibility that someone could substitute fake ballots that put those options in an order that is determinable mathematically from the ballot number. What checks are put in place for proving that the order has not been manipulated (beyond the usual physical security on ballots, which has been insufficient at preventing ballot stuffing for years)?
But again, if we have problems with ballot stuffing in corrupt districts, it would be just as easy for someone to swap out the real ballots with fake ones printed elsewhere before voters cast their votes. Unless the ballots are physically printed on-the-fly, there's not sufficient protection from that sort of attack.
...because it is not guaranteed to work correctly on all future architectures, even those that are backwards-compatible to current architectures
Emphasis mine. That means that when a new architecture comes out that supports i386 binaries, those binaries still won't run because the architecture reported by the kernel won't match any of the architectures that the script knows about.
... but FatELF has the same problem. A FatELF binary doesn't compile a new version of itself whenever it encounters a new arch; it merely selects among the existing bundled binaries to see which one is appropriate.
No, that's not correct. With a fat binary, the operating system chooses which one is appropriate. A newer OS that runs on x86_128 will know that the chip supports emulating x86_64 binaries natively, and will run that slice if it exists. A shell script that is part of the application cannot do that unless you or someone else rewrites it.
add a shell/library/kernel/whatever function to determine "are you $ARCH-compatible?" and expose that to scripts
Those of us who actually care about inode counts think such a scheme is an insanely bad idea. This means that for every binary with three architectures (say i386, i386+SSE3, x86_64), you now have three binary files and a script file instead of one file. You've just increased the number of inodes your OS takes by a significant amount. Even if the user then strips out all but one binary, you've still doubled the number of executable files; you can't just replace the script with the binary you want to keep because you can't be absolutely certain that neither the binary nor any executable that uses that binary expects it to be in the old location. Replace it with a symlink? You're still using an inode.
Also, you still aren't solving the bigger problem, which is libraries. As soon as you link in a library that needs to be able to load with more than one architecture, your "simpler" scheme blows up to an unholy mess with multiple trees of libraries, multiple library paths, having to compile each slice of the binary completely separately because they end up with different sets of LDFLAGS for each link line, etc. In the end, it ends up being MUCH, MUCH easier to use fat binaries than to try to hack something on top with shell scripts. In the long run, it is almost ALWAYS easier to do it right than to do a hack, and in the time you spend screwing around with that hack and making every developer's life miserable, people are jumping ship to other platforms that get it right the first time.
Sometimes I think that user forums and developer forums should be one and the same---that developers should be forced to see the user flame wards---that by exposing them to this without the option to get rid of it, they will be inspired to actually write software that is easier to configure and use. Maybe it's just me.
I had to screw around with MythTV for days just to get up and running, mostly because the features I wanted were off on a branch that never got merged in, the client-server protocol is not designed well enough to ensure compatibility across different versions, lirc is an abomination to get working with some of its drivers (and much of the process isn't well documented), the drivers were out of date, the new drivers weren't compatible with old versions of the code one level up, the channel guide data provider story was a train wreck (and again, not well documented), and so on.
Setting up MythTV is very much like taking people out into a forest, giving them some iron ore, and telling them to build a house. First, they have to forge a saw out of iron ore, then sharpen the teeth individually with rocks, then cut down the trees, then.... And most of the problems are just plain boneheaded architectural decisions involving lack of backwards protocol compatibility or binary compatibility---the sorts of things that commercial OSes and software generally do very well and open source tends to ignore because they mistakenly think it doesn't matter. It matters.
Another really big advantage is easier developer workflow. With multi-architecture binaries and libraries, you can test and debug the 32-bit and 64-bit versions of an application without rebooting into a separate OS, without building some weird chroot environment, without using a special linker that changes the paths of the libraries if it detects a 32-bit binary, etc. This means that your development system is essentially identical to the user systems (except for the kernel), and thus the likelihood of bizarre "Unable to reproduce" bugs goes way down.
Another big advantage is that if you build a universal install DVD, you have half as many binary packages. That means a less complex installer and thus reduced potential for bugs, reduced install testing overhead, etc.
Another big advantage is that when a user finds a 64-bit-specific bug in a tool, the user can do an "arch i386 grep 'blahblahblah' *" instead and work around it until somebody comes up with a fix. Without fat binaries, that's well beyond the ability of most typical computer users, including many IT people. You might as well tell them to fix the bug themselves. That doesn't do anybody any good....
But probably the most important reason for it is that Linux is late to the party. Many other operating systems support fat binaries---Mac OS X, Windows, NetBSD, etc. It's not like this is a new idea, nor is there a lack of a clear benefit. Obviously if there weren't clear benefits, there wouldn't be such broad support for this concept. And that's not just a bandwagon appeal; people judge operating systems by what they can do, and if there's an important, user-visible feature that one OS is missing, that's a win for operating systems that do have the feature....
Actually, I realized that it would have to shift every 25 ballots. Otherwise, it would repeat every 26th ballot; for all values of n, (n * 26) MOD 26 = 0. Oops. Still, if you have 300 candidates/ballot measure checkboxes, that gives you, if my sleepy math is right, about 7500 ballots before you repeat at all. That would be good enough for many smaller districts.
Shift the shift numbers backwards by three slots every thousand and you've ensured that the repeat occurs about 21 ballot slots away, likely on a different page, making it even less likely to be detected, and you won't get a repeat on the same page until you've gone through tens of thousands of ballots if you pick the numbers right. That's enough for large districts.
Add something like swapping the nth set of shift numbers with the n+kth set after every hundred ballots, where k is the hundreds place of the ballot number, then repeat for all values of n (e.g. if the 100s place is a 3, you swap sets 1 and 4, 2 and 5, etc.) and you've just raised the level of apparent randomness high enough that for any reasonable district size, you aren't going to detect it by a human looking for duplication, period. (Within a district, the probability of the same three characters being in the same spot is, I believe, lower than the odds of it occurring by chance, so it is trivially detectable by broad statistical analysis, of course.) Yet with such a scheme, determining who someone voted for is still computationally within the realm of possibility using a mere programmable calculator.
With a scheme like this, we are asked to trust that the ballots were printed legitimately by a printing machine that we can neither examine nor validate based on the contents of the ballots themselves. It's a cool idea, but I just don't have that much faith in our elected officials....:-) We have to assume adversaries have much better access to the inner workings of the voting system than we do, so if we want to protect people from being coerced into voting a particular way, we have to design a voting system that takes that into account....
Similarly, our current paper ballots are audited by candidates and by independent auditors. There's still fraud.:-) There are many attacks I can see on this scheme:
First, to be secure, this assumes that the auditor can remember every code from previous ballots to verify that are unique. Yet the instructions seem to indicate that the auditor sees only one ballot at a time instead of half a dozen ballots.
Even if they see multiple ballots, it's not a given that patterns will be detected. If you repeat the codes every 101 ballots, that would reduce the odds of detection to near zero without making it very hard at all to find out who someone voted for, so long as you have 101 blank ballots and know the voter's ballot number and codes. Or if there's a pattern, you might only need to be able to see one ballot and know the pattern.
Second, this ignores the possibility of an intelligent adversary colluding with an election official. It is trivial to generate a sequence of codes that are cryptographically trivially derived from one another that are mathematically related. For example, take a known starting pattern and shift each letter by... say (n *k) mod 26 where n is a different number for each letter of each candidate's code (but a known number) and k is the ballot number. Slide all of the codes down by 1 every 100 ballots, but keep the shift distances attached to the candidate and letter position. Doing this would result in a pattern that would appear random to all but the most cryptographically brilliant observers, but votes could still be trivially verified by anyone who knows the particular shift/mod scheme. All they would have to have is a particular person's three-letter codes, knowledge of the scheme, and access to a single ballot (any ballot) to provide a reference point for comparison.
Third, the problem of disenfranchised voters can result in mass voter fraud just like incorrectly recorded votes, and it's unlikely you'll be able to do anything about it when it happens. How do you cause mass disenfranchisement of votes with this system? Print up one fake ballot that has the same code numbers as another fake ballot. Introduce both, and flag them for auditing. BAM. That district's votes get tossed out. You've just eliminated a district that always votes heavily for one party, and have thrown the vote to the other party.
I could probably go on, but you get the idea. This is a cool idea, but ultimately electronic voting can provide much better protections against vote fraud than paper voting, assuming you do it correctly (with mandatory paper trail, separate manufacturers for a vote verifying machine than the vote taking machine, paper tokens from the verifier machine with cryptographic hashes of the vote using a UUID generated instantaneously at vote time keyed off the voting machine/time of day/PRNG, and so on. And still none of that guarantees that your vote really got counted, but the ability to total up the numbers in multiple places at least makes it very hard to inject or discard votes without going through the disenfranchisement process.
But the practical implementation could provide a way to prove that they voted for someone. My cynical suspicion is that by the second or third election, they'll use mass-produced ballots ballots that only have three or four different sets of codes on them to reduce the cost of ballot printing. And no one will be the wiser except for the people exploiting it. Where this system fails is in proving that the codes are truly unique. The only way you can guarantee that is if instead of using fixed printed codes, you provide the person with an electronically-generated cryptographic hash of the vote data with a random number that the voter cannot obtain.
Maybe I'm missing something, but for this to be truly secure against the problem of being able to see who somebody else voted for, you would have to have a distinct set of three-digit codes for every ballot, or at least such a large number of distinct ballots that no person could practically conspire with a few other people to figure out that XWP in the third field means Hillary Clinton. Wouldn't printing each ballot individually result in a tremendous cost compared with traditional ballot printing? I'm just trying to understand how this could be feasible on a large scale....
Of course it is. Any argument to the contrary is economic voodoo. By saying the economy isn't zero-sum, you're falling victim to the broken window fallacy. Every dollar spent paying down the debt is a dollar not spent on something else. There's only a certain amount of work that Americans can do every year, you know. You can only push workers so hard before they revolt....
Another way to look at a trade deficit is that the US economy is so powerful, it's able to raise the standard of living in the entire rest of the world.
... by borrowing money against future revenue. Eventually, somebody is going to start calling our debt, and then we are royally screwed. And even if they don't, if those debts aren't reasonably secured by a sufficient GDP, we won't be able to get loans. At some point, we are going to have to pay that money back, and anyone who thinks otherwise is kidding him/herself.
Borrowing with no intent to ever repay the debt is the sort of thinking that has led to mass foreclosures, the near collapse of lots of major U.S. banks, etc. It is a short-term solution that keeps the government in business through a brief downturn, but you cannot rely on it as a long-term source of funding.
The U.S. plugs are generally pretty solid unless your connectors are bent. Normally, the only time you bend pins is if you A. step on the plug, or B. yank the thing out of the outlet in a dangerous way. I'd rather have the cord come OUT of the outlet when I trip on it than stay in, though, making the U.S. plug actually safer than the British plug precisely because of its lack of robustness. The British plugs are too big, too cumbersome, too heavy duty for normal consumer electronics. It's like they were designed for air conditioners. The outlet adapter for British power takes up the same space in my luggage as three of the two-pin European adapters that I use for 99% of my electronic devices.
Also, this article mistakenly claims that the British plug is the only one that guarantees you put the right pins in the right holes. That's not true. The U.S. has both three-prong versions that do this and polarized two-prong versions that also do this. Similarly, the Denmark plug also does this, as does the French three prong plug (the one with the ground pin sticking out of the socket), though apparently there aren't any standards for which pin should be neutral versus hot in the socket itself, making this superfluous....
The absolute worst ones, though, I do agree, are the European standard, but not for the reasons they give. They're awful because there are at least two or three different pin spacings that look identical until you realize that you brought the wrong one and it won't fit into the socket. And there are half a dozen different standards for the third grounding pin, which is why we have such a huge rash of travel converters that don't provide the third pin. (Go ahead. Try to find a travel converter with a ground pin. Why is it that way? Because of the lack of standards in European power connectors, primarily.)
The U.S. power connector should ideally have thicker prongs for the two main prongs, and I wouldn't object to reversing the design, using round prongs for hot and neutral with a thick, flat bar for ground so that you could potentially have greater surface area for the ground contact, and thus better grounding. That said, it's still a lot better than the British connector because it doesn't weigh half a pound just for the connector....:-D
Having a car lie to you and say your going 65 when your going 60 is better (and less likely to cause liability and outrage for speeding tickets) than a speedometer saying your going 60 when your going 65.
Exactly. Automobile manufacturers in many places are liable for damages if they report a speed that is slower than you are actually going. Thus, many (not all) intentionally miscalibrate their speedometers to read about 5% faster than reality to give themselves a safety margin at highway speeds even if the gear in the optical counter loses a tooth or gets clogged.
I disagree. Wisdom requires knowledge. The ability to analyze the limited available information and make a choice that seemed like a good idea at the time is plain old intelligence. Wisdom is the combination of intelligence and knowledge---the analytical ability to make good choices based on the available information (intelligence) and the storehouse of general information (knowledge) that you use to fill in gaps in problem-specific information.
Actually, in this case, that's probably a very good piece of advice, at least with the 32-bit Mac OS X kernel. If I understand correctly, the only reason this is relevant is that in Linux and Windows, the kernel and user space have non-overlapping virtual address spaces. The Linux kernel uses a 3/1 split, the Windows kernel uses a 2/2 split (by default).
Mac OS X's 32-bit kernel, which uses a 4/4 "split" (completely overlapping address spaces), shouldn't be vulnerable because it should be impossible for code in the kernel to accidentally read data from a page mapped in a user-space process. I have no idea what the 64-bit Mac OS X kernel does in this regard.
It's not a complete picture, but it's actually worse than the GP said, not better. The U.S. actually has a trade deficit, which means that we have more money going out to other countries than we have coming in. Therefore, in effect, every dollar that goes to American businesses came out of the pockets of the general public. That's not perfectly precise, but that's the net effect. (Plus we're giving a little bit beyond that to foreign companies.)
Thus, it's entirely correct to divide dollars of debt by the number of American households to give a debt per household figure. The only way that would be wrong would be if we had a positive trade balance such that other countries were helping to pay off that national debt. As long as we have a trade deficit, we're paying for it, and whether we pay for it directly through our own taxes or in the form of higher prices for goods and services caused by business taxes, the net result is the same. We're paying for it. All of it.
3.7, assuming that's mg/dL, is dangerously low. High is having total cholesterol over 240 mg/dL. Anything under 200 is safe. For LDL, you should try to keep it under 40 mg/dL. For HDL, you should try to keep it *above* 60 mg/dL.
Also, IMHO, triglyceride levels are much more important. Try to keep that as low as possible and the cholesterol won't be as much of a problem.
It's a curious thing, but of the statins, though they all reduce blood cholesterol to similar levels, only one of them actually reduces the risk of heart disease in clinical trials, if memory serves. What does that tell us? Lowering cholesterol by itself doesn't do any good.... If you have excessively high cholesterol, there's something else wrong---probably inflammation of the heart muscle---that causes the cholesterol to build up in the first place.
Slashdot Mirror
I think you're closer than they are. My gut says it has more to do with the CNS nerves being encased in a hard shell (skull, spine) for their protection, and that this shell also puts an absolute limit on nerve growth beyond which additional growth would cause damage.
But the deaths started rolling in when the virus first hit Philadelphia, not after it had been bouncing around the community for months killing a tiny fraction of a percent of the people who got it. Growth of any illness is generally exponential based on contact, but death rate is generally linear in the number of infected. Therefore, if we're seeing a low death rate as a percentage of the population (and we are for H1N1), we will still see a low death rate as a percentage even if everyone got it. Judging from current stats, even if everyone in the U.S. got swine flu---every single man, woman, and child, based on current mortality figures, there would still be less than a factor of ten increase in deaths from the seasonal flu, and it is highly unlikely that we will see anywhere near a 100% infection rate.
Put another way, the chances of a virus mutating from killing single digit people to tens of thousands overnight are slim, and are probably equally likely whether you're talking about a mutation of H1N1 or of the common cold.
I think most of the folks saying "call me when it exceeds 36,000 deaths in a year" are really saying, "call me when the death toll is significantly higher than seasonal flu as a percentage of the infected or the percentage of exposed people who get infected is dramatically higher." In other words, "call me when the predicted annual death rate is expected to exceed 36,000 in a year." And that's a perfectly reasonable position.
And more specifically, alien invasion.
No, the same total binary package size, twice the size for any given individual binary package. Of course, that's only a small percentage of the size of a typical OS distribution. ISTR that binaries are usually somewhere around 30% by volume. So if you add a second architecture, you've only added 30% to the size of the distro. You've also made it easier to ship one DVD instead of two, made it easier to create a single boot drive that works on a wider range of machines without sacrificing 64-bit or SSE3 on machines that support it, etc.
Because you get dependencies that can't be met because somebody forgot to compile one library for one architecture and that breaks something else, which breaks something else.... Or because somebody forgot to adjust that library path to install in a different directory for the 64-bit slice and the two binaries clobber one another.... Or because somebody screwed up and included one path in the Perl @INC path that corresponds with the opposite architecture and Perl throws a fit and fails to load a Perl module even though the one for the right architecture is there, just later in @INC.... Or because autoconf isn't smart enough to do the right thing in every case when the user needs to compile something. It's not just the installer complexity that's a problem. Having multiple library sets in different locations dramatically increases the complexity of almost everything on the system.
Since the COM file format, supported way to heck back in DOS.
That's the idea, yes.
gcc -o foo foo.c -L/usr/lib/ -lfoo
Instead of:
gcc -o foo foo.c -L/usr/lib/ -lfoo
gcc -o foo foo.c L/usr/lib64/ -lfoo
One library path for both architectures instead of two.
When they run out. :-D But seriously, reducing the number of files you create also significantly reduces install times even if you're writing the same amount of data. There's a non-negligible performance overhead in creating hundreds of thousands of extra files. And even if you only write out binaries for a single architecture, there's a non-zero performance hit to walking the larger directory trees on the install media, seeking farther because of the extra files from the architectures you skip, etc. Or you could ship separate DVDs, but then you're back to the user having to choose before they even get the OS up and running. And if they choose something that should work, but doesn't due to critical kernel bugs (been there, done that), then they get to download a whole separate ISO (and maybe even reinstall).
Not at all. Take the case where there's a bug in a piece of software. In many cases, bugs behave differently or don't reproduce on all architectures. Thus, you may be able to work around the bug by running something in a different architecture. Also, third-party binaries are a great reason for having fat binaries, but they're nearly useless unless you also have fat libraries. As soon as you have built-in system libraries that are thin, you run a significant risk of having some libraries only installed for one architecture and not on another. This can easily turn the problem of choosing which slice to run into a case of the user having to manually run a particular slice, which is not a good user experience. That doesn't usually happen if you have all your system libraries built fat (unless somebody explicitly strips the libraries to a single architecture to save a few megs of disk space, in which case they deserve what they get).
IIRC, at least the RPM format is single-architecture unless they've changed that recently. I can't comment on the other packaging formats. Single-architecture binary packages with multi-architecture docs/non-binary-files packages certainly did seem to be the most typical design pattern last time I checked, but then again, I've avoided building packages like the plague lately, so I could be behind the times.
No, no it isn't. What's done is a colossal hack job in which everything gets built more than once, with different linker lines with different lib directories. And although I haven't created my own distro since that mess went in, I can tell just by looking at it that it is likely to be fragile and error-prone for the people who do. If I had to build a Linux distro now... well, I wouldn't build a Linux distro now. I think my reply would involve several swear words, followed by my resignation. :-D
Speaking as somebody who beat my head against a wall dealing with cross-compilation in Linux for a while at my previous employer, are you sure you want to ask me that? Yeah. I can think of many examples where a script can't do it. We'll start with the easy one: Perl. Try to configure a multi-architecture version of Perl that way and ship it as part of an OS distro. I dare you. Building the binary is the easy part (and last I checked, it was still a total disaster involving hacking up the build script). After that, you now have to keep track of multiple trees full of binary modules, one per architecture, making sure that every one built correctly on every architecture, etc. With fat binaries, it becomes relatively easy. Each of those modules builds only ONCE, building each file several times, once per architecture. Each module either builds or it doesn't. The amount of overhead for the package maintainers is much, much less.
Oh, and remember that as soon as you get one app that does its own custom @INC hack to add a new directory full of Perl modules, you now get to hack up that Perl script to look in multiple places, depending on architecture. The problem can rapidly escalate for end users in a complex installation. Oh, and judging from history, they'd arbitrarily change the layout and the startup scripts every couple of releases, breaking all of those changes over and over. Versus a multi-architecture fat binary install where it stays in the same location, version number notwithstanding, and it doesn't matter what hardware you're running on. And since it's built into the kernel's binary format, people are much less likely to screw with it just because "It would be even better if we move this here and change this like that."
I suspect if I thought about it harder, I could come up with many more examples of problems you'd have just with Perl alone, not to mention other similarly complex kits (PHP, Ruby, etc.). They all pretty much have the same sorts of problems, and for the same reasons.
You either have the order of the codes or you don't. If you do, then anyone with access to that table can determine who someone voted for. If you don't, then the ballots can't be audited. So is this basically assuming that the Q table will never get leaked? *confused*
Okay, so you have a table with a list of what the valid options would be for a given ballot without giving the order. This still leaves open to the possibility that someone could substitute fake ballots that put those options in an order that is determinable mathematically from the ballot number. What checks are put in place for proving that the order has not been manipulated (beyond the usual physical security on ballots, which has been insufficient at preventing ballot stuffing for years)?
But again, if we have problems with ballot stuffing in corrupt districts, it would be just as easy for someone to swap out the real ballots with fake ones printed elsewhere before voters cast their votes. Unless the ballots are physically printed on-the-fly, there's not sufficient protection from that sort of attack.
Reread the post you replied to:
Emphasis mine. That means that when a new architecture comes out that supports i386 binaries, those binaries still won't run because the architecture reported by the kernel won't match any of the architectures that the script knows about.
No, that's not correct. With a fat binary, the operating system chooses which one is appropriate. A newer OS that runs on x86_128 will know that the chip supports emulating x86_64 binaries natively, and will run that slice if it exists. A shell script that is part of the application cannot do that unless you or someone else rewrites it.
Those of us who actually care about inode counts think such a scheme is an insanely bad idea. This means that for every binary with three architectures (say i386, i386+SSE3, x86_64), you now have three binary files and a script file instead of one file. You've just increased the number of inodes your OS takes by a significant amount. Even if the user then strips out all but one binary, you've still doubled the number of executable files; you can't just replace the script with the binary you want to keep because you can't be absolutely certain that neither the binary nor any executable that uses that binary expects it to be in the old location. Replace it with a symlink? You're still using an inode.
Also, you still aren't solving the bigger problem, which is libraries. As soon as you link in a library that needs to be able to load with more than one architecture, your "simpler" scheme blows up to an unholy mess with multiple trees of libraries, multiple library paths, having to compile each slice of the binary completely separately because they end up with different sets of LDFLAGS for each link line, etc. In the end, it ends up being MUCH, MUCH easier to use fat binaries than to try to hack something on top with shell scripts. In the long run, it is almost ALWAYS easier to do it right than to do a hack, and in the time you spend screwing around with that hack and making every developer's life miserable, people are jumping ship to other platforms that get it right the first time.
Sometimes I think that user forums and developer forums should be one and the same---that developers should be forced to see the user flame wards---that by exposing them to this without the option to get rid of it, they will be inspired to actually write software that is easier to configure and use. Maybe it's just me.
I had to screw around with MythTV for days just to get up and running, mostly because the features I wanted were off on a branch that never got merged in, the client-server protocol is not designed well enough to ensure compatibility across different versions, lirc is an abomination to get working with some of its drivers (and much of the process isn't well documented), the drivers were out of date, the new drivers weren't compatible with old versions of the code one level up, the channel guide data provider story was a train wreck (and again, not well documented), and so on.
Setting up MythTV is very much like taking people out into a forest, giving them some iron ore, and telling them to build a house. First, they have to forge a saw out of iron ore, then sharpen the teeth individually with rocks, then cut down the trees, then.... And most of the problems are just plain boneheaded architectural decisions involving lack of backwards protocol compatibility or binary compatibility---the sorts of things that commercial OSes and software generally do very well and open source tends to ignore because they mistakenly think it doesn't matter. It matters.
Another really big advantage is easier developer workflow. With multi-architecture binaries and libraries, you can test and debug the 32-bit and 64-bit versions of an application without rebooting into a separate OS, without building some weird chroot environment, without using a special linker that changes the paths of the libraries if it detects a 32-bit binary, etc. This means that your development system is essentially identical to the user systems (except for the kernel), and thus the likelihood of bizarre "Unable to reproduce" bugs goes way down.
Another big advantage is that if you build a universal install DVD, you have half as many binary packages. That means a less complex installer and thus reduced potential for bugs, reduced install testing overhead, etc.
Another big advantage is that when a user finds a 64-bit-specific bug in a tool, the user can do an "arch i386 grep 'blahblahblah' *" instead and work around it until somebody comes up with a fix. Without fat binaries, that's well beyond the ability of most typical computer users, including many IT people. You might as well tell them to fix the bug themselves. That doesn't do anybody any good....
But probably the most important reason for it is that Linux is late to the party. Many other operating systems support fat binaries---Mac OS X, Windows, NetBSD, etc. It's not like this is a new idea, nor is there a lack of a clear benefit. Obviously if there weren't clear benefits, there wouldn't be such broad support for this concept. And that's not just a bandwagon appeal; people judge operating systems by what they can do, and if there's an important, user-visible feature that one OS is missing, that's a win for operating systems that do have the feature....
Actually, I realized that it would have to shift every 25 ballots. Otherwise, it would repeat every 26th ballot; for all values of n, (n * 26) MOD 26 = 0. Oops. Still, if you have 300 candidates/ballot measure checkboxes, that gives you, if my sleepy math is right, about 7500 ballots before you repeat at all. That would be good enough for many smaller districts.
Shift the shift numbers backwards by three slots every thousand and you've ensured that the repeat occurs about 21 ballot slots away, likely on a different page, making it even less likely to be detected, and you won't get a repeat on the same page until you've gone through tens of thousands of ballots if you pick the numbers right. That's enough for large districts.
Add something like swapping the nth set of shift numbers with the n+kth set after every hundred ballots, where k is the hundreds place of the ballot number, then repeat for all values of n (e.g. if the 100s place is a 3, you swap sets 1 and 4, 2 and 5, etc.) and you've just raised the level of apparent randomness high enough that for any reasonable district size, you aren't going to detect it by a human looking for duplication, period. (Within a district, the probability of the same three characters being in the same spot is, I believe, lower than the odds of it occurring by chance, so it is trivially detectable by broad statistical analysis, of course.) Yet with such a scheme, determining who someone voted for is still computationally within the realm of possibility using a mere programmable calculator.
With a scheme like this, we are asked to trust that the ballots were printed legitimately by a printing machine that we can neither examine nor validate based on the contents of the ballots themselves. It's a cool idea, but I just don't have that much faith in our elected officials.... :-) We have to assume adversaries have much better access to the inner workings of the voting system than we do, so if we want to protect people from being coerced into voting a particular way, we have to design a voting system that takes that into account....
Similarly, our current paper ballots are audited by candidates and by independent auditors. There's still fraud. :-) There are many attacks I can see on this scheme:
First, to be secure, this assumes that the auditor can remember every code from previous ballots to verify that are unique. Yet the instructions seem to indicate that the auditor sees only one ballot at a time instead of half a dozen ballots.
Even if they see multiple ballots, it's not a given that patterns will be detected. If you repeat the codes every 101 ballots, that would reduce the odds of detection to near zero without making it very hard at all to find out who someone voted for, so long as you have 101 blank ballots and know the voter's ballot number and codes. Or if there's a pattern, you might only need to be able to see one ballot and know the pattern.
Second, this ignores the possibility of an intelligent adversary colluding with an election official. It is trivial to generate a sequence of codes that are cryptographically trivially derived from one another that are mathematically related. For example, take a known starting pattern and shift each letter by... say (n *k) mod 26 where n is a different number for each letter of each candidate's code (but a known number) and k is the ballot number. Slide all of the codes down by 1 every 100 ballots, but keep the shift distances attached to the candidate and letter position. Doing this would result in a pattern that would appear random to all but the most cryptographically brilliant observers, but votes could still be trivially verified by anyone who knows the particular shift/mod scheme. All they would have to have is a particular person's three-letter codes, knowledge of the scheme, and access to a single ballot (any ballot) to provide a reference point for comparison.
Third, the problem of disenfranchised voters can result in mass voter fraud just like incorrectly recorded votes, and it's unlikely you'll be able to do anything about it when it happens. How do you cause mass disenfranchisement of votes with this system? Print up one fake ballot that has the same code numbers as another fake ballot. Introduce both, and flag them for auditing. BAM. That district's votes get tossed out. You've just eliminated a district that always votes heavily for one party, and have thrown the vote to the other party.
I could probably go on, but you get the idea. This is a cool idea, but ultimately electronic voting can provide much better protections against vote fraud than paper voting, assuming you do it correctly (with mandatory paper trail, separate manufacturers for a vote verifying machine than the vote taking machine, paper tokens from the verifier machine with cryptographic hashes of the vote using a UUID generated instantaneously at vote time keyed off the voting machine/time of day/PRNG, and so on. And still none of that guarantees that your vote really got counted, but the ability to total up the numbers in multiple places at least makes it very hard to inject or discard votes without going through the disenfranchisement process.
*sigh*
But the practical implementation could provide a way to prove that they voted for someone. My cynical suspicion is that by the second or third election, they'll use mass-produced ballots ballots that only have three or four different sets of codes on them to reduce the cost of ballot printing. And no one will be the wiser except for the people exploiting it. Where this system fails is in proving that the codes are truly unique. The only way you can guarantee that is if instead of using fixed printed codes, you provide the person with an electronically-generated cryptographic hash of the vote data with a random number that the voter cannot obtain.
Maybe I'm missing something, but for this to be truly secure against the problem of being able to see who somebody else voted for, you would have to have a distinct set of three-digit codes for every ballot, or at least such a large number of distinct ballots that no person could practically conspire with a few other people to figure out that XWP in the third field means Hillary Clinton. Wouldn't printing each ballot individually result in a tremendous cost compared with traditional ballot printing? I'm just trying to understand how this could be feasible on a large scale....
Of course it is. Any argument to the contrary is economic voodoo. By saying the economy isn't zero-sum, you're falling victim to the broken window fallacy. Every dollar spent paying down the debt is a dollar not spent on something else. There's only a certain amount of work that Americans can do every year, you know. You can only push workers so hard before they revolt....
... by borrowing money against future revenue. Eventually, somebody is going to start calling our debt, and then we are royally screwed. And even if they don't, if those debts aren't reasonably secured by a sufficient GDP, we won't be able to get loans. At some point, we are going to have to pay that money back, and anyone who thinks otherwise is kidding him/herself.
Borrowing with no intent to ever repay the debt is the sort of thinking that has led to mass foreclosures, the near collapse of lots of major U.S. banks, etc. It is a short-term solution that keeps the government in business through a brief downturn, but you cannot rely on it as a long-term source of funding.
The U.S. plugs are generally pretty solid unless your connectors are bent. Normally, the only time you bend pins is if you A. step on the plug, or B. yank the thing out of the outlet in a dangerous way. I'd rather have the cord come OUT of the outlet when I trip on it than stay in, though, making the U.S. plug actually safer than the British plug precisely because of its lack of robustness. The British plugs are too big, too cumbersome, too heavy duty for normal consumer electronics. It's like they were designed for air conditioners. The outlet adapter for British power takes up the same space in my luggage as three of the two-pin European adapters that I use for 99% of my electronic devices.
Also, this article mistakenly claims that the British plug is the only one that guarantees you put the right pins in the right holes. That's not true. The U.S. has both three-prong versions that do this and polarized two-prong versions that also do this. Similarly, the Denmark plug also does this, as does the French three prong plug (the one with the ground pin sticking out of the socket), though apparently there aren't any standards for which pin should be neutral versus hot in the socket itself, making this superfluous....
The absolute worst ones, though, I do agree, are the European standard, but not for the reasons they give. They're awful because there are at least two or three different pin spacings that look identical until you realize that you brought the wrong one and it won't fit into the socket. And there are half a dozen different standards for the third grounding pin, which is why we have such a huge rash of travel converters that don't provide the third pin. (Go ahead. Try to find a travel converter with a ground pin. Why is it that way? Because of the lack of standards in European power connectors, primarily.)
The U.S. power connector should ideally have thicker prongs for the two main prongs, and I wouldn't object to reversing the design, using round prongs for hot and neutral with a thick, flat bar for ground so that you could potentially have greater surface area for the ground contact, and thus better grounding. That said, it's still a lot better than the British connector because it doesn't weigh half a pound just for the connector.... :-D
Exactly. Automobile manufacturers in many places are liable for damages if they report a speed that is slower than you are actually going. Thus, many (not all) intentionally miscalibrate their speedometers to read about 5% faster than reality to give themselves a safety margin at highway speeds even if the gear in the optical counter loses a tooth or gets clogged.
I disagree. Wisdom requires knowledge. The ability to analyze the limited available information and make a choice that seemed like a good idea at the time is plain old intelligence. Wisdom is the combination of intelligence and knowledge---the analytical ability to make good choices based on the available information (intelligence) and the storehouse of general information (knowledge) that you use to fill in gaps in problem-specific information.
Actually, in this case, that's probably a very good piece of advice, at least with the 32-bit Mac OS X kernel. If I understand correctly, the only reason this is relevant is that in Linux and Windows, the kernel and user space have non-overlapping virtual address spaces. The Linux kernel uses a 3/1 split, the Windows kernel uses a 2/2 split (by default).
Mac OS X's 32-bit kernel, which uses a 4/4 "split" (completely overlapping address spaces), shouldn't be vulnerable because it should be impossible for code in the kernel to accidentally read data from a page mapped in a user-space process. I have no idea what the 64-bit Mac OS X kernel does in this regard.
It's not a complete picture, but it's actually worse than the GP said, not better. The U.S. actually has a trade deficit, which means that we have more money going out to other countries than we have coming in. Therefore, in effect, every dollar that goes to American businesses came out of the pockets of the general public. That's not perfectly precise, but that's the net effect. (Plus we're giving a little bit beyond that to foreign companies.)
Thus, it's entirely correct to divide dollars of debt by the number of American households to give a debt per household figure. The only way that would be wrong would be if we had a positive trade balance such that other countries were helping to pay off that national debt. As long as we have a trade deficit, we're paying for it, and whether we pay for it directly through our own taxes or in the form of higher prices for goods and services caused by business taxes, the net result is the same. We're paying for it. All of it.
3.7, assuming that's mg/dL, is dangerously low. High is having total cholesterol over 240 mg/dL. Anything under 200 is safe. For LDL, you should try to keep it under 40 mg/dL. For HDL, you should try to keep it *above* 60 mg/dL.
Also, IMHO, triglyceride levels are much more important. Try to keep that as low as possible and the cholesterol won't be as much of a problem.
It's a curious thing, but of the statins, though they all reduce blood cholesterol to similar levels, only one of them actually reduces the risk of heart disease in clinical trials, if memory serves. What does that tell us? Lowering cholesterol by itself doesn't do any good.... If you have excessively high cholesterol, there's something else wrong---probably inflammation of the heart muscle---that causes the cholesterol to build up in the first place.