The point is that the current electoral college system is a gross approximation of the popular vote, where the results in each state (with a few exceptions) is rounded up to its size. This allows candidates of both parties to write off many entire states with known outcomes, and concentrate disproportionately on the swing states. Any move towards a more proportional system means that the swing states are less important, and will receive proportionately less attention.
the number of electors per state is N+2, where N is (supposedly) the population multiplied by a constant. Thus in a state with a smaller population, each person gets a slightly more powerful vote even if the electors are distributed proportionally. Whether this is a good thing or a bad thing is another matter.
There are many ways to slice this cake. If you want to honor the power of the state, you can give each state one vote and elect the candidate with 26 or more state votes. You can also move all the way back to simple popular vote, which honors the power of each citizen.
Everything in between the two extremes is basically an arbitrary weighting to favor some specific groups. In theory, it's possible to find an ideal set of weights that require candidates to shower everybody with the right amount of attention, but who would you prefer to pick that weighting fairly in practice?
hey, we wrote the Japanese constitution and made the Empiror publicly declare he wasn't a god, and that all worked out.
Japan was occupied for nearly seven years. America not only wrote their new constitution, but executed hundreds of war criminals, dissolved large companies, implemented land reform, censored the media, and so on. The point is, Iraq is probably in far worse shape today than Japan was in 1946, so "all worked out" can be a decade from now even with extensive American involvement.
If America worked by direct democracy, the candidates would only have to win the huge urban areas like New York and Los Angeles in order to win the presidency. The Electoral College, at least partly, ensures that candidates have to win other places, too [...]
If you want to argue that the Electoral College could be improved (for example, make it proportional instead of winner-takes-all), i might agree with you.
I think you contradict yourself. If the electoral college system was proportional, then the candidates would in fact have to concentrate their efforts on the population centers. In fact, the only thing a proportional electoral college gives you is a rounded-off version of the popular vote. It's whole point was to be disproportionate.
Yes. Even the UN claimed that over 300,000 people were killed by Saddam's regime.
...over a 23 year reign, which makes it an average of about 13,000 deaths each year. America alone lost about 1,000 troops in Iraq in the past 12 months, and it would not at all be surprising if at least 12,000 Iraqis have also died in the same period. (Some 100,000 Iraqi soldiers died in Kuwait in 1991, while the US lost less than 300 soldiers.)
If you're looking only at the body count, which let me first say is a skewed way of examining things, the US occupation so far probably was not any less bloody than Saddam's reign.
I didn't say they weren't niches. (Hard-core gaming, by the way, is also a niche.) I simply said you were overgeneralizing to say "unless you feel the need to play games, there was no reason to upgrade."
Re:Finally a voice of reason
on
Less Might Be More
·
· Score: 4, Insightful
Let's face it: unless you feel the need to play games, there was no reason to upgrade your computer for the past six years.
Or encode video streams. Or compile code. Let's not paint with such a broad brush.
Ah, no. Either the text is scaled to approximately the right size and the web page doesn't fit on the screen, or the page fits and the fonts are scaled down to 1 pt = 1 px. You can't have it both ways.
What I listed were two separate uses of a small high resolution display. That is, the usual phone text (menu, messages, etc) are unlikely to become much smaller, but can be shown in higher quality. Additionally, the mobile browser on the phone has a better chance of displaying a web page properly, even if it means smaller text. You can have both, just not simultaneously.
A point is generally defined as 1/72 of an inch, and does not vary with display resolution. Thus, on a 96 dpi screen, 6 pt text is defined by about 8 pixels. On a 300 dpi screen, the same text can use about 25 pixels to define the glyph. The text itself stays the same size.
As for icons and graphics, they can be redrawn to better suit the display size. Compared to the other expenses involved in building a cell phone, redrawing 100 icons is not really a very big one.
Putting that res in a screen that small seems pretty pointless.
You have something against sharper text and graphics? We're talking about a 300 ppi display, which matches the resolution of first-generation laser printers. Text will be readable at as little as 6 points (nearly 25 pixels!), and a web page just might be displayed decently.
The only regret you'll have from paying for too much quality is the money. You'll have everything to regret from spending on too little quality.
That's a nice thing for a professor to advocate, but real world projects like the space shuttle do not have an infinite budget to accomplish the assigned task. Therefore, spending too much money on one aspect can mean that another is sacrificed and becomes the point of failure. Therefore, while being responsible for the part that never failed is an understandable source of pride, it may actually reveal a misallocation of resources.
Engineering is about spending the least amount of time and money to achieve the required quality. Nobody said anything about spending too little.
You can make an up-down controller simulate relative behaviour by automatically returning the "knob" to the neutral position after the user is done. [...] It's not the way you'd expect a scroll bar in a computer to work, though
Video editors are familiar with a horizontal widget that looks like a scroll bar, but is normally centered when the mouse button is released. Dragging it to the right causes the tape to fast-forward (with a speed corresponding to how far you drag), and dragging it to the left fast-reverses the tape. A physical rotary input device (some of which snap back to the middle position when released) is also common for this purpose.
Either is more convenient than the usual VCR buttons.
Mr Kevlin Henney was praising NASA's rigorous software testing procedures. He was so proud of them that he let out a "and in both space shuttle crashes, software was not to blame".
This may sound a bit funny, but perhaps some of the software budget should've been shifted to the parts of the shuttles that did break, or parts that may have saved the astronauts. Obviously not so much of it that the software ends up broken, but overengineering a module in a system is only slightly less wrong than underengineering it.
Re:Not all problems are solvable
on
Security Alert
·
· Score: 1
a book of anecdotes about "real people" and contemporary information security is almost going to be inherently uninformative. How could you possibly cover all the seams that todays severely limited security models leave open?
You can't, but covering the ones you read about is better than not covering them. Having true stories to relate to your users can make a bigger impact on them than just hypothetical risks that you made up.
Presumably you have to link several times as well, which mean the link time *still* dominates.
I'm not arguing as to which is dominant, but whether compile time is negligible.
Early on, the project isn't as big, so a complete build isn't as bad.
I've never joined that commercial project that early. They've all been already pretty big, and getting bigger. This means that it's my usage pattern (big changes + build vs. small change + build) that determines the percentage of my time is spent waiting for the build versus coding or testing.
At least, you probably need to set off more time for refactoring. Using a faster compiler sound more like a band-aid than a solution. Too strong coupling has other (and more serious) bad effects than long compile times.
I don't disagree. However, I'm not saying that a faster compiler is the best solution to our problems. I'm telling you that compile time is a problem, not only for those who don't know how to write makefiles.
I always get confused about people claiming compile time is important for development. It seems to be people who make a habbit of compiling everything from scratch. Haven't they heard of make?
It depends on the project. Working on a cross-platform project means that a developer must make several builds before checking in a change. You don't have to compile everything from scratch for that to quickly add up.
It also depends on the phase of the project. Early on, it's more likely that developers make big changes before compiling. After code completion, it's more likely that developers make one or two line bug fixes and need to re-compile.
[...] And then I have to link all 236 files, which is where the time is spend. I can see it compile time being important to people who use the compiler as an install tool (like gentoo users), but not for any serious developers.
The project that my team is working on contains nearly 10,000 targets, not all of which have very good dependencies set up as the software aged. I guess we're not serious developers.
The lack of bounds checking might not be a criticism of the language per se but it's certainly a criticism of the language as it's used.
Correct, but it would be a mistake to propose a replacement of the language for another (and throwing away a lot of valuable experience) just because it is commonly misused. If the language is not fundamentally flawed, then the answer might be to find a better implementation of it. GCC, for example, optionally supports bounds-checking for both heap and stack objects.
buffer overflows are inherent problems in C/C++ [...] Java on the other hand does not allow programmers to make that error.
First, you need to separate the language from the implementations. Buffer overflows formally result in "undefined behavior" in both C and C++, which means the implementation is allowed to do anything with it - including shutting the errant program down with no further damage.
Most C and C++ implementations do not do that, and it is a real difference, but that has nothing to do with the language.
If more people used better tools it would mean less security problmens.
You make a leap of faith here that would only be immediately true if Java was identical to C or C++ in all respects except buffer overflows. Java is a different language, with different strengths and weaknesses. It is not necessarily the better tool for every situation (which includes available programmer skill).
Both as a software professional and a consumer of software products, I despise warranty disclaimers because they let many companies negligently ship poor products. But as somebody who needs a paycheck, I must ask how much people will be willing to pay for warrantied software.
Oh, but the alternate envronment can do more to save battery energy. Like run a non-x86 processor (all of which deliver more MIPS/watt). A simple $5 ARM is sufficient if MPEG decoding is done in hardware.
Where do you want to play the movie from? Spinning the DVD is likely to be the costliest in terms of power, so let's copy the movie to the hard disk. Ooops, now your $5 ARM must run a FAT32 file system to be able to read the movie. Some people use NTFS? Well, that's some more code. Would a second CPU, MPEG decoder chip, and two filesystems cost less than a spare battery? (And even then Linux users will still complain that it doesn't read ext2!) Did you plan to share the onboard RAM with your second processor? How would that be wired?
Configuring an OS to shut off that stuff is clumsy because it doesn't "know" that you don't want them (unless you go into configuration & tell it).
What's so hard about a DVD player app that shuts off unnecessary stuff when in fullscreen playback mode? Hell, add a "dedicated play" mode.
I think a lot of posts here are confusing "multitasking OS doesn't currently do this" with "have to go back to singletasking OS".
Computers would be more stable, like consoles. Do you know why consoles are becoming the status quo for gamers? Because the games are written for one specific system and it just works.
One, computers are stable. My Windows 2000 and XP installations basically don't crash. My Mac doesn't crash, either. The ones that do crash are almost always the applications!
Two, the distinguishing characteristic of the Wintel PC market is the abundance of hardware choices. There is no "specific system" to "just work" on. I love Macs, but people are not abandoning Wintel en masse because of "just works".
Three, as with Linux, hardware device manufacturers either refuse to or cannot afford to support anything except the monopoly operating system. That's unlikely to change with your hundred little operating systems dream.
Four, vendors will still not tailor each application to maximize the system. They already don't do that today at the price point you're willing to pay. Whether you like it or not, the OS platform saves developers a lot of time and money.
Who says you can't have a program running that launches other programs and multitasks them? Why do we depend on unfriendly OSes that take full control of our systems, when our software could do the same and operate independantly?
The hardware says you can't. An ethernet card cannot physically send two packets from two different applications at the same time. One must go first. Video cards, particularly ones with 3-D support, are generally stateful and cannot deal with two or more simultaneous clients. In all such cases, software serializes access to them.
Even sharable resources must have an owner. For example, if you don't know or care who "owns" the RAM when you write to it, you can clobber another application. Software must allocate RAM to those who ask for it to avoid this.
It is simply impossible for software to operate independently and share system resources at the same time.
Let's face it, there are apps you want to multitask and there are apps you don't. You could have the ability to multitask if you wanted your session that way, or if you just want to focus on one app you could.
You are solving an imaginary problem. You should cite some examples where idle or background multitasking actually impacts the performance of a single application appreciably. Bring up a process monitor in your favorite OS, and you'll see that the cost of idling is so low that it's generally not worth the cost of optimizing it away.
Multitasking doesn't mean that the OS distributes CPU time to each running task evenly. What you're arguing is that the 95% or 99% devoted to the foreground task is not enough and worth optimizing for. The first one is less meaningful each day thanks to Moore's Law, and the second one is pretty questionable even today.
In extreme cases (think Pixar's render farm or Google's servers), it's worthwhile to hire dedicated programmers to tune each bit of your computer system to get the best performance possible. However, neither Pixar nor Google had the inclination to write their own OS from scratch. The theoretical savings of a single-tasking system simply aren't worth it.
eMusic competes with iTunes by providing non-DRMed MP3 files. Of course they don't have as much major label stuff
Exactly, so it's still not the same question. You are asserting that Apple would use DRM anyway even if the major labels didn't require it. I'm saying that their supposed desire to control everything isn't enough proof that they would, because they'd have competition who are then likely to offer the exact same songs without DRM. Therefore, the question is, with such competition is Apple likely to stick to its DRM guns?
protecting our own works (via commercial license, GPL, Doberman Pinscher, or electric fence) does not destroy a right or freedom that anyone else enjoyed.
It does. Copyright, in the US at least, is an incentive given by the public to professional artists so they can feel safe to create and distribute their works. The public did not give up the right to hum whatever tune it likes for nothing. In return, the public asks that at the end of your copyright term, the work reverts to the public domain.
DRM files do not revert to the public domain. With laws like the DMCA, building a tool to crack the DRM on a work with expired copyright might still be illegal, as long as the same DRM scheme still protects currently copyrighted works. These technical means can effectively extend copyright protection far beyond what the law had promised.
Slashdot Mirror
The point is that the current electoral college system is a gross approximation of the popular vote, where the results in each state (with a few exceptions) is rounded up to its size. This allows candidates of both parties to write off many entire states with known outcomes, and concentrate disproportionately on the swing states. Any move towards a more proportional system means that the swing states are less important, and will receive proportionately less attention.
the number of electors per state is N+2, where N is (supposedly) the population multiplied by a constant. Thus in a state with a smaller population, each person gets a slightly more powerful vote even if the electors are distributed proportionally. Whether this is a good thing or a bad thing is another matter.
There are many ways to slice this cake. If you want to honor the power of the state, you can give each state one vote and elect the candidate with 26 or more state votes. You can also move all the way back to simple popular vote, which honors the power of each citizen.
Everything in between the two extremes is basically an arbitrary weighting to favor some specific groups. In theory, it's possible to find an ideal set of weights that require candidates to shower everybody with the right amount of attention, but who would you prefer to pick that weighting fairly in practice?
Japan was occupied for nearly seven years. America not only wrote their new constitution, but executed hundreds of war criminals, dissolved large companies, implemented land reform, censored the media, and so on. The point is, Iraq is probably in far worse shape today than Japan was in 1946, so "all worked out" can be a decade from now even with extensive American involvement.
If you want to argue that the Electoral College could be improved (for example, make it proportional instead of winner-takes-all), i might agree with you.
I think you contradict yourself. If the electoral college system was proportional, then the candidates would in fact have to concentrate their efforts on the population centers. In fact, the only thing a proportional electoral college gives you is a rounded-off version of the popular vote. It's whole point was to be disproportionate.
If you're looking only at the body count, which let me first say is a skewed way of examining things, the US occupation so far probably was not any less bloody than Saddam's reign.
I didn't say they weren't niches. (Hard-core gaming, by the way, is also a niche.) I simply said you were overgeneralizing to say "unless you feel the need to play games, there was no reason to upgrade."
Or encode video streams. Or compile code. Let's not paint with such a broad brush.
What I listed were two separate uses of a small high resolution display. That is, the usual phone text (menu, messages, etc) are unlikely to become much smaller, but can be shown in higher quality. Additionally, the mobile browser on the phone has a better chance of displaying a web page properly, even if it means smaller text. You can have both, just not simultaneously.
A point is generally defined as 1/72 of an inch, and does not vary with display resolution. Thus, on a 96 dpi screen, 6 pt text is defined by about 8 pixels. On a 300 dpi screen, the same text can use about 25 pixels to define the glyph. The text itself stays the same size.
As for icons and graphics, they can be redrawn to better suit the display size. Compared to the other expenses involved in building a cell phone, redrawing 100 icons is not really a very big one.
You have something against sharper text and graphics? We're talking about a 300 ppi display, which matches the resolution of first-generation laser printers. Text will be readable at as little as 6 points (nearly 25 pixels!), and a web page just might be displayed decently.
What's the downside?
Here's the oversimplified breakdown:
- eMac - low end home/school desktop ($799, $999)
- iBook - low end home/school laptop ($1099, $1299, $1499)
- iMac - mid-range home/school desktop ($1299, $1499, $1899)
- PowerMac - high end professional desktop ($1999, $2499, $2999)
- PowerBook - high end professional laptop ($1599, $1799, $1999, $2499, $2799)
The pricing basically tells you what each is meant to be. The iMac is most definitely not meant to cannibalize PowerMac sales.That's a nice thing for a professor to advocate, but real world projects like the space shuttle do not have an infinite budget to accomplish the assigned task. Therefore, spending too much money on one aspect can mean that another is sacrificed and becomes the point of failure. Therefore, while being responsible for the part that never failed is an understandable source of pride, it may actually reveal a misallocation of resources.
Engineering is about spending the least amount of time and money to achieve the required quality. Nobody said anything about spending too little.
Video editors are familiar with a horizontal widget that looks like a scroll bar, but is normally centered when the mouse button is released. Dragging it to the right causes the tape to fast-forward (with a speed corresponding to how far you drag), and dragging it to the left fast-reverses the tape. A physical rotary input device (some of which snap back to the middle position when released) is also common for this purpose.
Either is more convenient than the usual VCR buttons.
This may sound a bit funny, but perhaps some of the software budget should've been shifted to the parts of the shuttles that did break, or parts that may have saved the astronauts. Obviously not so much of it that the software ends up broken, but overengineering a module in a system is only slightly less wrong than underengineering it.
You can't, but covering the ones you read about is better than not covering them. Having true stories to relate to your users can make a bigger impact on them than just hypothetical risks that you made up.
I'm not arguing as to which is dominant, but whether compile time is negligible.
Early on, the project isn't as big, so a complete build isn't as bad.
I've never joined that commercial project that early. They've all been already pretty big, and getting bigger. This means that it's my usage pattern (big changes + build vs. small change + build) that determines the percentage of my time is spent waiting for the build versus coding or testing.
At least, you probably need to set off more time for refactoring. Using a faster compiler sound more like a band-aid than a solution. Too strong coupling has other (and more serious) bad effects than long compile times.
I don't disagree. However, I'm not saying that a faster compiler is the best solution to our problems. I'm telling you that compile time is a problem, not only for those who don't know how to write makefiles.
It depends on the project. Working on a cross-platform project means that a developer must make several builds before checking in a change. You don't have to compile everything from scratch for that to quickly add up.
It also depends on the phase of the project. Early on, it's more likely that developers make big changes before compiling. After code completion, it's more likely that developers make one or two line bug fixes and need to re-compile.
[...] And then I have to link all 236 files, which is where the time is spend. I can see it compile time being important to people who use the compiler as an install tool (like gentoo users), but not for any serious developers.
The project that my team is working on contains nearly 10,000 targets, not all of which have very good dependencies set up as the software aged. I guess we're not serious developers.
Correct, but it would be a mistake to propose a replacement of the language for another (and throwing away a lot of valuable experience) just because it is commonly misused. If the language is not fundamentally flawed, then the answer might be to find a better implementation of it. GCC, for example, optionally supports bounds-checking for both heap and stack objects.
First, you need to separate the language from the implementations. Buffer overflows formally result in "undefined behavior" in both C and C++, which means the implementation is allowed to do anything with it - including shutting the errant program down with no further damage.
Most C and C++ implementations do not do that, and it is a real difference, but that has nothing to do with the language.
If more people used better tools it would mean less security problmens.
You make a leap of faith here that would only be immediately true if Java was identical to C or C++ in all respects except buffer overflows. Java is a different language, with different strengths and weaknesses. It is not necessarily the better tool for every situation (which includes available programmer skill).
Both as a software professional and a consumer of software products, I despise warranty disclaimers because they let many companies negligently ship poor products. But as somebody who needs a paycheck, I must ask how much people will be willing to pay for warrantied software.
Where do you want to play the movie from? Spinning the DVD is likely to be the costliest in terms of power, so let's copy the movie to the hard disk. Ooops, now your $5 ARM must run a FAT32 file system to be able to read the movie. Some people use NTFS? Well, that's some more code. Would a second CPU, MPEG decoder chip, and two filesystems cost less than a spare battery? (And even then Linux users will still complain that it doesn't read ext2!) Did you plan to share the onboard RAM with your second processor? How would that be wired?
Configuring an OS to shut off that stuff is clumsy because it doesn't "know" that you don't want them (unless you go into configuration & tell it).
What's so hard about a DVD player app that shuts off unnecessary stuff when in fullscreen playback mode? Hell, add a "dedicated play" mode.
I think a lot of posts here are confusing "multitasking OS doesn't currently do this" with "have to go back to singletasking OS".
One, computers are stable. My Windows 2000 and XP installations basically don't crash. My Mac doesn't crash, either. The ones that do crash are almost always the applications!
Two, the distinguishing characteristic of the Wintel PC market is the abundance of hardware choices. There is no "specific system" to "just work" on. I love Macs, but people are not abandoning Wintel en masse because of "just works".
Three, as with Linux, hardware device manufacturers either refuse to or cannot afford to support anything except the monopoly operating system. That's unlikely to change with your hundred little operating systems dream.
Four, vendors will still not tailor each application to maximize the system. They already don't do that today at the price point you're willing to pay. Whether you like it or not, the OS platform saves developers a lot of time and money.
Who says you can't have a program running that launches other programs and multitasks them? Why do we depend on unfriendly OSes that take full control of our systems, when our software could do the same and operate independantly?
The hardware says you can't. An ethernet card cannot physically send two packets from two different applications at the same time. One must go first. Video cards, particularly ones with 3-D support, are generally stateful and cannot deal with two or more simultaneous clients. In all such cases, software serializes access to them.
Even sharable resources must have an owner. For example, if you don't know or care who "owns" the RAM when you write to it, you can clobber another application. Software must allocate RAM to those who ask for it to avoid this.
It is simply impossible for software to operate independently and share system resources at the same time.
Let's face it, there are apps you want to multitask and there are apps you don't. You could have the ability to multitask if you wanted your session that way, or if you just want to focus on one app you could.
You are solving an imaginary problem. You should cite some examples where idle or background multitasking actually impacts the performance of a single application appreciably. Bring up a process monitor in your favorite OS, and you'll see that the cost of idling is so low that it's generally not worth the cost of optimizing it away.
Multitasking doesn't mean that the OS distributes CPU time to each running task evenly. What you're arguing is that the 95% or 99% devoted to the foreground task is not enough and worth optimizing for. The first one is less meaningful each day thanks to Moore's Law, and the second one is pretty questionable even today.
In extreme cases (think Pixar's render farm or Google's servers), it's worthwhile to hire dedicated programmers to tune each bit of your computer system to get the best performance possible. However, neither Pixar nor Google had the inclination to write their own OS from scratch. The theoretical savings of a single-tasking system simply aren't worth it.
Shame on you for pirating games that don't even exist. That's like stealing, you know.
Exactly, so it's still not the same question. You are asserting that Apple would use DRM anyway even if the major labels didn't require it. I'm saying that their supposed desire to control everything isn't enough proof that they would, because they'd have competition who are then likely to offer the exact same songs without DRM. Therefore, the question is, with such competition is Apple likely to stick to its DRM guns?
It does. Copyright, in the US at least, is an incentive given by the public to professional artists so they can feel safe to create and distribute their works. The public did not give up the right to hum whatever tune it likes for nothing. In return, the public asks that at the end of your copyright term, the work reverts to the public domain.
DRM files do not revert to the public domain. With laws like the DMCA, building a tool to crack the DRM on a work with expired copyright might still be illegal, as long as the same DRM scheme still protects currently copyrighted works. These technical means can effectively extend copyright protection far beyond what the law had promised.
That's not part of the deal.