No, we're not (even ignoring the various "free shipping" setups that places like Amazon have on orders of sufficient size). More precisely, we don't pay for it from the point of view of the courier services. We're not the ones who actually give them money, and we're not the ones (more importantly!) who decide which service to ship with. We can certainly vote with our wallets and not shop at merchants who ship via shipping services that are too big a hassle for us, but in practice that doesn't happen on a wide enough scale to have an effect.
> if you miss your package, they leave a receipt in your mail box, and tell you to pick it > up at the nearest "post office".
Typically it's not the nearest one but the nearest "big" one. At least in my experience.
> I put post office in quotes because the post office is usually the neighbourhood > pharmacy or convenience store
Definitely not my experience with the USPS.
> I really don't understand why UPS, Fedex, et al couldn't work out a similar deal > with local stores
They could, but it would cost them money. And since the package recipient is not their customer, it's not worth it to them. Which is precisely the problem with said companies.
> My basic guess is, is that courier services really only care about delivering to > businesses.
They certainly operate as if that were the case.
> They charge rates only businesses would pay, and therefore, their residential customers > are almost nil.
That doesn't follow, since the rate is paid by the _sender_. Their residential senders are nil. Their residential _recipients_ are anyone who buys stuff online, basically. Very few e-tailers have the option of shipping via USPS, because for them the courier services offer all sorts of conveniences (e.g. package pickup).
So yes, the courier services are terrible for recipients, good for senders. The senders are the ones paying them; the rest follows from this.
> when has the USPS stopped you from going to FedEx, UPS, DHL, ect.
For sending, never.
However, the primary customer of all those services is the sender. They couldn't care less about the recipient, except insofar as it might piss off the sender. And they're aimed primarily at the business market with their delivery times. And on the receiving end, USPS sometimes has special privileges.
Case in point: in Chicago, the USPS, unlike all the other entities you mention, has master keys to the front doors of many apartment buildings (NOT the individual apartment doors). They need these so that they can get to the mailboxes, which are inside the lobby area. This means they can also leave packages in the lobby area, instead of out on the street (or not at all, which is what all the other services will do). If a package actually requires a signature and they keep missing you, getting to the local post office in a city is a lot easier than getting to whatever boondocks location FedEx and company want you to go to for picking up the package (a 30 minute drive from where I was in the case of UPS; completely inaccessible without a car).
Totally agreed with your other point, though. I doubt UPS and FedEx deliver to the US territory which is the south pole station in Antarctica, for example.
I meant specifically the object-heavy DOM API required by SVG, where everything in sight is an object, including things that would be better off as strings (the.href of an , for example, just in case you want to use SMIL to animate that; same thing for.className on all SVG elements). Oh, except you have to also provide it all in string form for the Core DOM APIs.
Having personally worked on a browser DOM implementation and done a fair amount of black-box testing of three other browse DOM implementations, a lot of the "shittiness" is baked into the specs. The SVG example is pretty typical: instead of using strings where they make sense, objects where they make sense, and something radical like integers where _they_ make sense, the DOM APIs typically require you to keep information in multiple forms at once and sync them to each other when any of the representations is changed. Setters are typically provided for all the different representations. In practice implementations often end up violating the letter of the spec and using a canonical representation in some cases just to keep performance sane. If the representations could be generated from each other, this wouldn't even violate the spec... but they can't be.
There's nothing flawed with the concept of an object model, of course, just with the design-by-committee object models the W3C has produced.
> Well, upload is a niche market (though I admit, I'd love to be able to get at least a > megabit...Even half a megabit would be nice).
Upload can gate your download throughput, at least if you're talking TCP. Packet size on the downstream packets is limited, and you have to send ACKs. ACK packets are 40 bytes. So if your downstream bandwidth is 10x your upstream and your MTU below 400 or so, your upstream bandwidth is what determines how much TCP traffic you can actually get.
In practice, MTUs are closer to 1500 if everything is going well, and the ratio of down to up is usually no worse than 6:1, so the issue rarely arises.
Honestly, the XML-and-DOM part of SVG is a significant performance drag. If you want high-performance 3d graphics, you do NOT want to be maintaining a DOM for the whole thing...
> * Large install base with very fast uptake on new versions.
Fast uptake? Or do you mean "major versions" as opposed to security fixes? Flash uptake for security fixes is terrible.
> * Small file size for the plugin, support for Window, OS X and Linux.
Sort of. 64-bit support is not so great. Support is not at all the same across all three of Windows, OS X, Linux (e.g. windowless mode took its sweet time coming to all three).
You forgot some negatives:
* Unstable (something like 30% of the crashes logged by the Firefox crash logger are actually Flash crashes... note that this is for in-development Firefox builds, last I checked; the numbers look worse for release ones). * CPU hog. Disabling Flash drops my browser's CPU usage from 40-50% to 2-5%. This is on Mac. Your mileage will vary by operating system and number of sites with Flash in them you have open.
Note that it's not a given that the replacement will be less of a CPU hog or less crashy. But if it's not.... it won't kill Flash.
* IAttachmentExecute (present starting with XP SP2) * dynamic loading of uxtheme code (present starting with XP, not there in Win2k, since the
whole Windows themes thing started with XP); if Win2k support went away the dynamic
loading hackery could disappear, and uxtheme could just be linked to directly.
That actually seems to be it, from the linked thread.
Ah, yes. That wonderful blog post by Ben. This is a guy who was no longer active in Firefox development at the time and hadn't been for a while (close to a year). Before that be wasn't exactly working on memory issues either. So yes, he was being precisely a fanboy in that blog post: commenting about things he knew nothing about (all the bfcache stuff postdated his involvement, for example) while being completely blind to the actual issues involved.
Again, I challenge you to point to anyone actively involved with the Mozilla project at the time who said anything other than "yes, there seems to be a problem; we're working on it".
> The problem was it took them a LONG time to react.
So your real issue is that the lag time from Gecko 1.8 to Gecko 1.9 was so long? That's a legitimate complaint, certainly. But note that during that entire cycle work to reduce memory usage was done on a large scale, ranging from fundamentally changing memory management for DOM-exposed objects to switching out the allocator used when it was determined that the system malloc sucks on some of the OSes in question.
The malloc work was the last piece of work on the "memory leak" issue, and was done over a year before Firefox 3 actually shipped. Most of the other work happened well before; some before Firefox 2 even shipped. But Firefox 2 was using the same underlying Gecko as Firefox 1.5, more or less, so didn't see the benefits of the memory improvements...
I guess I'm not terribly interested in your replies either, if you're one of the people trotting out Ben's blog post, to be honest.
Oh, yeah. XP SP2 was brought up just because MS is going to drop support for it in a year. I don't think it's realistic to drop app support for it, and neither do a lot of other people.
> because XP is nearly the same core operating system.
It's the differences that make testing a huge hassle... And yes, there are XP APIs that Firefox uses that are not present on 2k, and yes we've had 2k-only bug reports that took up a lot of QA and developer time to deal with. So it's not silly at all to drop 2k support: it frees up people to work on other things.
If Firefox 3.5 is left behind, it will continued to be used at a decent clip for several
more years, making it one more PITA.... not to mention one more reason to recommend
Chrome over FF.
Other than 3.5 being the last supported version on some old Windows OSes, there's no reason to think it would be "left behind". Since Chrome wouldn't be usable on those OSes either, those users couldn't switch to it, even should they want to.
I have no problem with you liking the browser you like (though you seem to have some pretty weird ideas about how Firefox developers, as opposed to Firefox fanboys, reacted to the memory leak reports). But let's not try this FUD approach of saying "one more reason to recommend X over Y" in situations where Y would be in use in the first place for reasons that preclude using X.
So I don't see how Firefox maybe next year dropping support for OSes that Chrome already doesn't support is a reason to recommend Chrome over Firefox... Care to explain?
> 2000 and XP were released a year apart with next to 100% API compatibility with one > another.
Compat in the sense that 2k APIs work in XP, yes. The other direction, no. For example, to take advantage of the theming stuff in XP requires writing code that will work on XP but not on Win2k, because XP added some APIs that don't exist on Win2k.
It's certainly false for Win2k (which is the main thing support is being considered dropped for). The XP thing is a separate discussion, and I don't think the SP3 proposal is being taken very seriously honestly.
> Is Firefox doing anything (better question SHOULD it be) low level enough for the > current version to matter?
I'm not sure why you think that only low-level things change in OS release. APIs also get added (for example, the way virus scanning should be done on downloaded files changed from XP SP1 to XP SP2, as I recall, and that's certainly something a web browser needs to deal with, assuming it allows file downloads).
> The situation with FF on Linux it is bad enough, in that they don't do security fixes > for older versions, and new versions generally won't run on old Linux distributions
Sure they do, if the old distribution ships newer libraries. Or if you link against those libraries statically. This is what distributions whose users expect to not have to update (e.g. the enterprise distributions, CentOS, so forth) are doing.
It'd also all work if Linux happened to have a mature text-rendering library, say. Then one could write against an "old" library version and work everywhere (modulo stuff like current trunk Firefox not compiling against newest pango because pango changed its API incompatibly). But the fact of the matter is that if you want decent behavior (by which I mean not crashing exploitably, not leaking too much, actually providing hooks that you need, having decent performance) out of system pango you have to use a new version because the old ones are so buggy. If you want to integrate well with the system (e.g. use the OS print dialog) you have to use a new GTK version (because older ones just don't have the APIs for it).
Firefox could probably ship its own pango like it ships its own cairo. Heck, it could ship its own gtk version. But then people start complaining about bloat, about it not using their OS-wide font configuration, etc.
Really, it's not a matter of caring about Linux; if people didn't care about it it wouldn't be supported at all. The fact is, that a number of Mozilla developers use Linux, so they do care about it. But desktop linux is really in poor shape so far if you're trying to write software that will run on it across versions. I just spent over a week trying to accurately detect something Windows has had an API call for for at least 10 years now: are there any pending user events? In the end I ended up having to use raw Xlib calls, because gtk/gdk just doesn't provide any useful interfaces for this, and even the Xlib calls are a nasty hack (e.g. change the order of event delivery).
All that said, I'm not sure why you're singling Mozilla out here: a recent gtk won't run against an old pango either; a number of other apps need a recent gtk or recent pango.... It's a nasty mess, and I speak as someone who was running RH9 until about a year ago, so I know all about trying to get things to work on old Linux distributions.
> While there are exceptions, it is safe to say that those on the lower end of the > payscale work very hard jobs for very long hours
You're thinking low end of payscale, not low end of income, right? Note that while some of the people you describe do end up working very long hours, especially due to holding down multiple jobs, there are reasonably many jobs of this sort where hours are capped (and/or overtime pay paid for anything over 40 hours a week).
> whereas those in high paid executive positions are on a gravy train, with high salaries, > bonuses, short hours, little responsibility and who actually do atrociously little work.
In between, there are a great many people who get taxed rather heavily (more heavily than either of the two extremes you describe) and work very hard. Doctors are a typical example (though both the higher pay and the hard work are results of rationing by medical schools, in my opinion).
But the real issue is not that of tax rates affecting people in different professions but of tax rates _within_ a profession. To use your example of people on the low end of the pay scale, someone holding down two full-time jobs at $7 an hour ends up paying a higher fraction of their income as taxes than someone holding down only one such job, even though the former is almost certainly adding a lot more to the economy no matter how you slice it.
> I think you might mean good luck getting that many people to have a will and > exercise it outside of what the party they are aligned with already represents.
No, I meant good luck getting that many people to have a will an exercise it, period. Voter turnout numbers in the U.S. are pretty sub-stellar.
You're right that there is the additional hurdle of having a will outside your party; there are way too many people who literally vote the party line.
> It is more like 5-8% of all those who cast a vote for the position
No, 8% of those who voted in the last general election. There's a big difference, esp. in non-presidential-election years.
You might be right that the 30% number I saw was a result of redistricting, though.
> with the major parties getting a break on the requirements.
> All it take to get on the ballot is the signature of a certain amount of people.
That amount depends on the party. At least in Illinois. If you're not a Democrat or Republican you need a lot more signatures (30% of the registered voters in some congressional districts to end up on the ballot, in fact).
Good luck getting that many people to even have a will, much less exercise it.
That's not quite true, because the rules for getting on the ballot are not open to the will of the people... until you elect some new legislators. A bit of a Catch-22.
And yes, most times you can do write-ins. Most times. Not all.
> the most important freedom of a democracy or a republic is not the freedom to vote for > the candidate (though that is important) -- it the freedom the freedom to run for the > office.
At least in the U.S., this freedom is commonly subverted, especially on the national level. For example, Illinois has different requirements for getting yourself on the ballot as a presidential candidate depending on your party affiliation (about an order of magnitude range in number of signatures needed).
Thing is, that patch fixes the particular crash but not the vulnerability. And no one at the time recognized that this was a security issue (unlike the numerous non-exploitable crashes)....
It's still a problem, of course. I don't think anyone's happy that that patch didn't land.:(
Sadly, we're moving in the opposite direction: more and more in loco parentis on the part of universities, with parents suing universities if something happens to their precious darling while away at school...
> Second, this girl is 19 now. She was 13 when this happened. What happened to the concept > of "statute of limitations"? Why wasn't the case brought up when she was 13?
It almost certainly was. It just got picked up by the Supreme Court (which is what the article cited is about). Which means that it's already been through at least two courts (original court, plus the US Court of Appeals mentioned in the article).
The statute of limitations has no bearing on how long a court case should take if the side ruled against keeps appealing (as here; the Court of Appeals ruled against the school, and the school appealed to the Supreme Court).
Actually, there are all sorts of issues that are undefined with border-radius. How should it interact with background images? With border images? How should it work for table cells/rows/columns/rowgroups/colgroups in both table border models?
It's been taking years to sort these issues out with border-radius specifically; changes to how it behaves are still being made. So it's not a bad example at all.;)
Slashdot Mirror
No, we're not (even ignoring the various "free shipping" setups that places like Amazon have on orders of sufficient size). More precisely, we don't pay for it from the point of view of the courier services. We're not the ones who actually give them money, and we're not the ones (more importantly!) who decide which service to ship with. We can certainly vote with our wallets and not shop at merchants who ship via shipping services that are too big a hassle for us, but in practice that doesn't happen on a wide enough scale to have an effect.
> if you miss your package, they leave a receipt in your mail box, and tell you to pick it
> up at the nearest "post office".
Typically it's not the nearest one but the nearest "big" one. At least in my experience.
> I put post office in quotes because the post office is usually the neighbourhood
> pharmacy or convenience store
Definitely not my experience with the USPS.
> I really don't understand why UPS, Fedex, et al couldn't work out a similar deal
> with local stores
They could, but it would cost them money. And since the package recipient is not their customer, it's not worth it to them. Which is precisely the problem with said companies.
> My basic guess is, is that courier services really only care about delivering to
> businesses.
They certainly operate as if that were the case.
> They charge rates only businesses would pay, and therefore, their residential customers
> are almost nil.
That doesn't follow, since the rate is paid by the _sender_. Their residential senders are nil. Their residential _recipients_ are anyone who buys stuff online, basically. Very few e-tailers have the option of shipping via USPS, because for them the courier services offer all sorts of conveniences (e.g. package pickup).
So yes, the courier services are terrible for recipients, good for senders. The senders are the ones paying them; the rest follows from this.
> when has the USPS stopped you from going to FedEx, UPS, DHL, ect.
For sending, never.
However, the primary customer of all those services is the sender. They couldn't care less about the recipient, except insofar as it might piss off the sender. And they're aimed primarily at the business market with their delivery times. And on the receiving end, USPS sometimes has special privileges.
Case in point: in Chicago, the USPS, unlike all the other entities you mention, has master keys to the front doors of many apartment buildings (NOT the individual apartment doors). They need these so that they can get to the mailboxes, which are inside the lobby area. This means they can also leave packages in the lobby area, instead of out on the street (or not at all, which is what all the other services will do). If a package actually requires a signature and they keep missing you, getting to the local post office in a city is a lot easier than getting to whatever boondocks location FedEx and company want you to go to for picking up the package (a 30 minute drive from where I was in the case of UPS; completely inaccessible without a car).
Totally agreed with your other point, though. I doubt UPS and FedEx deliver to the US territory which is the south pole station in Antarctica, for example.
I meant specifically the object-heavy DOM API required by SVG, where everything in sight is an object, including things that would be better off as strings (the .href of an , for example, just in case you want to use SMIL to animate that; same thing for .className on all SVG elements). Oh, except you have to also provide it all in string form for the Core DOM APIs.
Having personally worked on a browser DOM implementation and done a fair amount of black-box testing of three other browse DOM implementations, a lot of the "shittiness" is baked into the specs. The SVG example is pretty typical: instead of using strings where they make sense, objects where they make sense, and something radical like integers where _they_ make sense, the DOM APIs typically require you to keep information in multiple forms at once and sync them to each other when any of the representations is changed. Setters are typically provided for all the different representations. In practice implementations often end up violating the letter of the spec and using a canonical representation in some cases just to keep performance sane. If the representations could be generated from each other, this wouldn't even violate the spec... but they can't be.
There's nothing flawed with the concept of an object model, of course, just with the design-by-committee object models the W3C has produced.
> Well, upload is a niche market (though I admit, I'd love to be able to get at least a
> megabit...Even half a megabit would be nice).
Upload can gate your download throughput, at least if you're talking TCP. Packet size on the downstream packets is limited, and you have to send ACKs. ACK packets are 40 bytes. So if your downstream bandwidth is 10x your upstream and your MTU below 400 or so, your upstream bandwidth is what determines how much TCP traffic you can actually get.
In practice, MTUs are closer to 1500 if everything is going well, and the ratio of down to up is usually no worse than 6:1, so the issue rarely arises.
Honestly, the XML-and-DOM part of SVG is a significant performance drag. If you want high-performance 3d graphics, you do NOT want to be maintaining a DOM for the whole thing...
> * Large install base with very fast uptake on new versions.
Fast uptake? Or do you mean "major versions" as opposed to security fixes? Flash uptake for security fixes is terrible.
> * Small file size for the plugin, support for Window, OS X and Linux.
Sort of. 64-bit support is not so great. Support is not at all the same across all three of Windows, OS X, Linux (e.g. windowless mode took its sweet time coming to all three).
You forgot some negatives:
* Unstable (something like 30% of the crashes logged by the Firefox crash logger are actually Flash crashes... note that this is for in-development Firefox builds, last I checked; the numbers look worse for release ones).
* CPU hog. Disabling Flash drops my browser's CPU usage from 40-50% to 2-5%. This is on Mac. Your mileage will vary by operating system and number of sites with Flash in them you have open.
Note that it's not a given that the replacement will be less of a CPU hog or less crashy. But if it's not.... it won't kill Flash.
* IAttachmentExecute (present starting with XP SP2)
* dynamic loading of uxtheme code (present starting with XP, not there in Win2k, since the
whole Windows themes thing started with XP); if Win2k support went away the dynamic
loading hackery could disappear, and uxtheme could just be linked to directly.
That actually seems to be it, from the linked thread.
Which part was lacking in tact, exactly? Pointing out that you were repeating rumors with little basis in reality, or something else?
Ah, yes. That wonderful blog post by Ben. This is a guy who was no longer active in Firefox development at the time and hadn't been for a while (close to a year). Before that be wasn't exactly working on memory issues either. So yes, he was being precisely a fanboy in that blog post: commenting about things he knew nothing about (all the bfcache stuff postdated his involvement, for example) while being completely blind to the actual issues involved.
Again, I challenge you to point to anyone actively involved with the Mozilla project at the time who said anything other than "yes, there seems to be a problem; we're working on it".
> The problem was it took them a LONG time to react.
So your real issue is that the lag time from Gecko 1.8 to Gecko 1.9 was so long? That's a legitimate complaint, certainly. But note that during that entire cycle work to reduce memory usage was done on a large scale, ranging from fundamentally changing memory management for DOM-exposed objects to switching out the allocator used when it was determined that the system malloc sucks on some of the OSes in question.
The malloc work was the last piece of work on the "memory leak" issue, and was done over a year before Firefox 3 actually shipped. Most of the other work happened well before; some before Firefox 2 even shipped. But Firefox 2 was using the same underlying Gecko as Firefox 1.5, more or less, so didn't see the benefits of the memory improvements...
I guess I'm not terribly interested in your replies either, if you're one of the people trotting out Ben's blog post, to be honest.
Oh, yeah. XP SP2 was brought up just because MS is going to drop support for it in a year. I don't think it's realistic to drop app support for it, and neither do a lot of other people.
> because XP is nearly the same core operating system.
It's the differences that make testing a huge hassle... And yes, there are XP APIs that Firefox uses that are not present on 2k, and yes we've had 2k-only bug reports that took up a lot of QA and developer time to deal with. So it's not silly at all to drop 2k support: it frees up people to work on other things.
What you said, and I quote was:
If Firefox 3.5 is left behind, it will continued to be used at a decent clip for several
more years, making it one more PITA.... not to mention one more reason to recommend
Chrome over FF.
Other than 3.5 being the last supported version on some old Windows OSes, there's no reason to think it would be "left behind". Since Chrome wouldn't be usable on those OSes either, those users couldn't switch to it, even should they want to.
I have no problem with you liking the browser you like (though you seem to have some pretty weird ideas about how Firefox developers, as opposed to Firefox fanboys, reacted to the memory leak reports). But let's not try this FUD approach of saying "one more reason to recommend X over Y" in situations where Y would be in use in the first place for reasons that preclude using X.
> not to mention one more reason to recommend Chrome over FF
Chrome doesn't support Windows before XP SP2, just so you know. See http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95411
So I don't see how Firefox maybe next year dropping support for OSes that Chrome already doesn't support is a reason to recommend Chrome over Firefox... Care to explain?
> 2000 and XP were released a year apart with next to 100% API compatibility with one
> another.
Compat in the sense that 2k APIs work in XP, yes. The other direction, no. For example, to take advantage of the theming stuff in XP requires writing code that will work on XP but not on Win2k, because XP added some APIs that don't exist on Win2k.
Can you back that up?
It's certainly false for Win2k (which is the main thing support is being considered dropped for). The XP thing is a separate discussion, and I don't think the SP3 proposal is being taken very seriously honestly.
> Is Firefox doing anything (better question SHOULD it be) low level enough for the
> current version to matter?
I'm not sure why you think that only low-level things change in OS release. APIs also get added (for example, the way virus scanning should be done on downloaded files changed from XP SP1 to XP SP2, as I recall, and that's certainly something a web browser needs to deal with, assuming it allows file downloads).
> The situation with FF on Linux it is bad enough, in that they don't do security fixes
> for older versions, and new versions generally won't run on old Linux distributions
Sure they do, if the old distribution ships newer libraries. Or if you link against those libraries statically. This is what distributions whose users expect to not have to update (e.g. the enterprise distributions, CentOS, so forth) are doing.
It'd also all work if Linux happened to have a mature text-rendering library, say. Then one could write against an "old" library version and work everywhere (modulo stuff like current trunk Firefox not compiling against newest pango because pango changed its API incompatibly). But the fact of the matter is that if you want decent behavior (by which I mean not crashing exploitably, not leaking too much, actually providing hooks that you need, having decent performance) out of system pango you have to use a new version because the old ones are so buggy. If you want to integrate well with the system (e.g. use the OS print dialog) you have to use a new GTK version (because older ones just don't have the APIs for it).
Firefox could probably ship its own pango like it ships its own cairo. Heck, it could ship its own gtk version. But then people start complaining about bloat, about it not using their OS-wide font configuration, etc.
Really, it's not a matter of caring about Linux; if people didn't care about it it wouldn't be supported at all. The fact is, that a number of Mozilla developers use Linux, so they do care about it. But desktop linux is really in poor shape so far if you're trying to write software that will run on it across versions. I just spent over a week trying to accurately detect something Windows has had an API call for for at least 10 years now: are there any pending user events? In the end I ended up having to use raw Xlib calls, because gtk/gdk just doesn't provide any useful interfaces for this, and even the Xlib calls are a nasty hack (e.g. change the order of event delivery).
All that said, I'm not sure why you're singling Mozilla out here: a recent gtk won't run against an old pango either; a number of other apps need a recent gtk or recent pango.... It's a nasty mess, and I speak as someone who was running RH9 until about a year ago, so I know all about trying to get things to work on old Linux distributions.
> While there are exceptions, it is safe to say that those on the lower end of the
> payscale work very hard jobs for very long hours
You're thinking low end of payscale, not low end of income, right? Note that while some of the people you describe do end up working very long hours, especially due to holding down multiple jobs, there are reasonably many jobs of this sort where hours are capped (and/or overtime pay paid for anything over 40 hours a week).
> whereas those in high paid executive positions are on a gravy train, with high salaries,
> bonuses, short hours, little responsibility and who actually do atrociously little work.
In between, there are a great many people who get taxed rather heavily (more heavily than either of the two extremes you describe) and work very hard. Doctors are a typical example (though both the higher pay and the hard work are results of rationing by medical schools, in my opinion).
But the real issue is not that of tax rates affecting people in different professions but of tax rates _within_ a profession. To use your example of people on the low end of the pay scale, someone holding down two full-time jobs at $7 an hour ends up paying a higher fraction of their income as taxes than someone holding down only one such job, even though the former is almost certainly adding a lot more to the economy no matter how you slice it.
> I think you might mean good luck getting that many people to have a will and
> exercise it outside of what the party they are aligned with already represents.
No, I meant good luck getting that many people to have a will an exercise it, period. Voter turnout numbers in the U.S. are pretty sub-stellar.
You're right that there is the additional hurdle of having a will outside your party; there are way too many people who literally vote the party line.
> It is more like 5-8% of all those who cast a vote for the position
No, 8% of those who voted in the last general election. There's a big difference, esp. in non-presidential-election years.
You might be right that the 30% number I saw was a result of redistricting, though.
> with the major parties getting a break on the requirements.
Which is a major issue, in my opinion.
> All it take to get on the ballot is the signature of a certain amount of people.
That amount depends on the party. At least in Illinois. If you're not a Democrat or Republican you need a lot more signatures (30% of the registered voters in some congressional districts to end up on the ballot, in fact).
Good luck getting that many people to even have a will, much less exercise it.
That's not quite true, because the rules for getting on the ballot are not open to the will of the people... until you elect some new legislators. A bit of a Catch-22.
And yes, most times you can do write-ins. Most times. Not all.
> the most important freedom of a democracy or a republic is not the freedom to vote for
> the candidate (though that is important) -- it the freedom the freedom to run for the
> office.
At least in the U.S., this freedom is commonly subverted, especially on the national level. For example, Illinois has different requirements for getting yourself on the ballot as a presidential candidate depending on your party affiliation (about an order of magnitude range in number of signatures needed).
Thing is, that patch fixes the particular crash but not the vulnerability. And no one at the time recognized that this was a security issue (unlike the numerous non-exploitable crashes)....
It's still a problem, of course. I don't think anyone's happy that that patch didn't land. :(
Sadly, we're moving in the opposite direction: more and more in loco parentis on the part of universities, with parents suing universities if something happens to their precious darling while away at school...
> Second, this girl is 19 now. She was 13 when this happened. What happened to the concept
> of "statute of limitations"? Why wasn't the case brought up when she was 13?
It almost certainly was. It just got picked up by the Supreme Court (which is what the article cited is about). Which means that it's already been through at least two courts (original court, plus the US Court of Appeals mentioned in the article).
The statute of limitations has no bearing on how long a court case should take if the side ruled against keeps appealing (as here; the Court of Appeals ruled against the school, and the school appealed to the Supreme Court).
Actually, there are all sorts of issues that are undefined with border-radius. How should it interact with background images? With border images? How should it work for table cells/rows/columns/rowgroups/colgroups in both table border models?
It's been taking years to sort these issues out with border-radius specifically; changes to how it behaves are still being made. So it's not a bad example at all. ;)