I haven't heard of any compiler that removes code just because it contains undefined behavior. All compilers I know of leave it in, and whether it misbehaves at run-time or not is... well, undefined. It may work just fine, eg. dereferencing a null pointer may just give you a block of zeroed-out read-only memory and what happens next depends on what you try to do with the dereferenced object. It may immediately crash with a memory access exception. Or it may cause all mounted filesystems to wipe and reformat themselves. But the code's still in the executable. I know compilers remove code that they've determined can't be executed, or where they've determined that the end state doesn't depend on the execution of the code, and that can cause program malfunctions (or sometimes cause programs to fail to malfunction, eg. an infinite loop in the code that didn't go into an infinite loop when the program ran because the compiler'd determined the code had no side-effects so it elided the entire loop).
I'd also note that I don't know any software developers who use the term "unstable code" as a technical term. That's a term used for plain old buggy code that doesn't behave consistently. And compilers are just fine with that kind of code, otherwise I wouldn't spend so much time tracking down and eradicating those bugs.
These aren't laws. They're private agreements between companies to limit poaching of employees. The only government interference here would be to make such agreements illegal, punishing companies that tried to limit the competition between them for the best employees.
The big problem is that we deregulated the cable and phone companies, but we didn't remove their monopoly agreements and we didn't enforce any regulations barring them from entering into non-compete agreements. So you end up with a situation like where I live, where Cox Cable isn't subject to regulation regarding rates, services and quality, etc. but at the same time no competing cable company's allowed in (because Cox still has an agreement with the city making them the only cable company allowed to run cable on the public right-of-way), the city attorney routinely enforces that agreement (taking legal action when one of the two cable companies in the area tries to provide service in an area assigned to the other, even when that other company isn't actually providing service in the affected area), and there's an agreement between Cox and Time-Warner (the other company in the area) not to offer service where the other's already providing it. End result: all the downsides of a monopoly combined with all the downsides of completely-unregulated services. They can do whatever they want with rates, there's no legal basis for challenging them, and there's no competitor you can switch to. To fix the problem we have to remove this pseudo-deregulation: either they're fully deregulated and not allowed to bar competition from entering the area, or they've got a monopoly on service and are subject to regulation as a public utility.
That's the thing, though: none of the news stories in my feed were posted by those major outlets. They're posted by other people I know, linking back to those major outlets. If News Corp. posts something, relatively few people will see it. It's only if those people repost it and other people are interested enough to want to re-repost it that it spreads and a lot of people see it. If that doesn't happen, odds on most people will never see it no matter what News Corp. does.
One of the biggest hurdles I always face as a software developer in private enterprise is upper management coming in and dictating not just what they want done but how it must be done and what technologies to use. Since they're not just unfamiliar with software development and technology in general but with the internal architecture and details of the systems the company has, the end result is the complete and utter mess you'd expect from say someone with no clue about cooking dictating how much of what ingredients a Cordon Bleu chef must use in a dish and how it must be cooked (as opposed to just telling him what dish you want and then getting out of the kitchen and letting him do the job you hired him for).
The pollsters missed it by the phrasing of their question. People aren't getting their news from Facebook. They're getting news from their friends and people they're following, who happen to be posting links to that news to Facebook. The difference is subtle but important. If someone goes "Oh, all we need to do is get our stories to appear on Facebook.", they're going to have their whole push fall on it's face because nobody's reading their articles. They'd need to get their articles in front of the people who lots of other people follow first, and make those articles interesting enough that those people post links to them for their followers to see. That's more complicated than just getting your story carried by a half-dozen major outlets.
I wouldn't add lag, I'd bucket it. 2 second windows. All trades in a 2-second window are collected by the exchange but not executed yet. When the window closes you take all the collected trades, shuffle them into a random order and execute them as if received in that order. Then wait for the next window to close and the next batch of trades to be processed.
Yes, this is going to thoroughly screw over anyone trying to take advantage of changes in prices over sub-2-second timeframes. The sensible reaction to that is to just not do that. Just like we don't spend hours cruising around repeatedly checking every gas station in town to see if they've changed prices during the day, because we know they usually only change prices once a day and you'll waste far more gas hunting for the rare exception than you'd ever save by it. Most people don't even drive all over looking for the absolute cheapest price, because they know they'll burn more on gas than they'll save getting a couple cents a gallon better price. They figure out which stations are usually the cheapest and just go there all the time, unless they happen to see an exceptional deal or notice another station routinely pricing below their usual one.
Literally. Microsoft touts all the capabilities built into Windows as advantages. The software and services to do all that are integrated into Windows. They aren't easy to remove. And the more things you have running, the more work the box has to do (even when it's idle, those services are still working in the background) and the more power it consumes. Android, OTOH, doesn't have all those services integrated into the OS, and it's a lot easier to remove unneeded services when they're separate components that you can just take out of the startup scripts.
After the state of IE10, I'm not surprised. I'm locked on IE9 because 10 isn't compatible with any of the webapps I need to access at work, ditto the Cisco SSL VPN software (I don't like browser-based VPNs, but I don't get to pick which VPN the company uses). At this point I can't afford to waste time experimenting with upgrading beyond 9, the compatibility issues are just too great for no perceptible gain (the best they could manage is to render Web pages as acceptably as 9 does, explain to me again why I'm wasting my time fighting to untangle compatibility issues to get back to where I started?).
The basic problem is that, while it sounds great in theory, in practice the transformations you want don't exist. If they did, you'd have software doing the job already and you wouldn't need to create it. Your business isn't going to go very far just doing the same thing everybody else is doing, is it? You need to be doing something they aren't. Which means, in this context, you need transformations that don't already exist (either because they haven't been written yet (ideally) or because the people who wrote them are keeping them confidential to keep you from copying what their business is doing (less than ideal)). So on top of your FBP team stringing components together, you're still going to need that expensive conventional development team to write the components for the FBP team to string together. You haven't saved much, in fact it's probably costing you more than just having the conventional dev team.
Plus, stringing components together isn't quite as simple as it sounds. Real-world systems usually depend on interaction and complex relationships between otherwise simple components. Keeping track of the synchronization between all those parts and keeping everything coordinated is usually the hard part. For instance, when creating an application to set up appointments the part where you take a set of existing appointment slots (some occupied, some free) and a set of one or more slots the customer would like ordered by preference and determine the best requested slot to put them in is easy. Picking up the current set of slots, putting them up on a Web page in a sensible way, letting the user select what ones work for them and set the order of preference, sending that information back to the server and, across this whole process, making sure that either nobody could alter the assigned appointments between the time you picked them up to display and the time the customer hit Submit and you started to sort out the assignment, that's nowhere near as simple. Doing this in a modern system with multiple servers where the submission may not go back to the server that handled the initial request, when you've got thousands of customers and hundreds of your users making, changing and cancelling appointments at the same time,... can we say "highly non-trivial"? And it really doesn't fit the FBP model at all.
Even where things fit the model, it's rarely as simple as "just string them together". I work with software that fits that model. Well, it did. Once. Long ago. And then the business people said "Oh, but customer A wants it do to some other thing if it's a transaction for them.". Followed by "Well, we want to do X, unless C applies in which case we want to do Y.". "Oh, unless M was specified for the account, in which case do X even when C applies except where X set V to 7 we need it set to 14.". Lather rinse repeat for 10 years and the quick one-line summary version ran to 5 pages single-spaced. Until that is we tried to print it out and found things were nested so deep some lines were starting past the right-hand edge of standard letter paper, so it's more like 10 pages, legal-sized, in landscape mode.
Client certificates shouldn't change, at least not until they expire. And for authentication the site should be issuing the certificate so they can control expiration. But yes, there's supposed to be support for all this. I think the primary blame is Internet Explorer: it wouldn't support anything but Basic authentication and Windows-specific methods, and it wouldn't work correctly with any unsupported methods unless Basic was the first method. Meanwhile other browsers followed the spec and used the first (most-preferred) method that they supported, so if you wanted to support IE you forced every other browser to use nothing better than Basic (and you had to support IE). So everyone lost track of all those authentication methods other than Basic. Bleh.
So they have to weigh up the risks to their kids compared to the benefits for my kid?
No. They have to weigh the benefits to their kid vs. the risks to their kid. As do you. If you're short-sighted, you'll look only at the direct risks and benefits of the vaccination and your kid in isolation. But that ignores the fact that your kid isn't in isolation, he's going to be exposed to all the other kids around (and they're going to be exposed to him). If you take that short-sighted approach, and everybody else does too, then the risk to your kid increases, due to increased exposure to the disease and increased susceptibility to the disease, by far more than any risk of reaction to the vaccine that you've avoided.
If I "save" $20 but it costs me $200 to do so (that I wouldn't have had to spend if I weren't trying to save that $20), I haven't saved anything at all.
I'd also note that there's upsides to having people interested in doing the minimum. As my father put it about the ore-processing mill he was general foreman of, "I don't want the industrious, energetic twit who'll muck out the basement on Monday because the tanks overflowed, and muck out the basement on Tuesday because the tanks overflowed, and muck out the basement on Wednesday because the tanks overflowed... I want the lazy bum who'll figure out why the tanks keep overflowing and fix it so they don't so he doesn't have to muck out the basement every day. He gets to goof off half his shift, I get a mill that's running smoothly, the company ain't paying any more than they were fine with paying the energetic twit, I fail to see a problem here.".
There's a problem with that: the laws that say hospitals can't turn people away when they show up in the ER with a problem. And frankly there's very good reasons for those laws. We had a system where hospitals wouldn't treat you if you couldn't pay, and it resulted in major public-health problems that were costing the country (not the government, the country) huge amounts of money to deal with. So we changed the system.
NB: we had the same situation and the same problems when we had private fire departments. We changed that system for the same kind of reason: out-of-control fires caused by fire departments not responding because none of the houses they were getting paid to protect was on fire yet, and by the time they did respond half the block was burning and there was no way to control the blaze.
The reason for the mandate (and for the original single-payer system) is that currently the cost of health care for the uninsured is hidden in the "uncollectable debt" category in the hospital's accounts receivable. It's all the bills for ER visits and emergency care for people who can't pay. I was taught a basic rule back in high school business classes: you can't manage costs until you've got them laid out where you can see them. The idea was to get all health care being paid for and accounted for so we can see where the money's going and do something about the areas where it's costing more than it should. It was also to help with shifting the costs from expensive emergency care to much cheaper preventative care, the idea being that when people know they're covered by insurance they're more likely to go to the doctor before things get critical instead of putting it off and hoping they get better so they don't get nailed with a doctor's bill and ending up at the ER in critical condition. If you have no insurance the bill's going to be a killer either way so it makes sense to go for the chance to avoid it, whereas if you do have insurance the bill won't kill you either way so why wait and suffer more than you have to?
Part of the problem is the usual problems with large-scale IT projects: it's not until you're well into it that you really get a grasp of what's involved. Nothing government-specific there, that plagues all large IT projects in private industry. Part of the problem, though, lies exactly in the fact that contractors were used. Contractors are mercenaries. They're here to deliver this project, and once they get their paycheck they're on to other work. They won't be around to deal with the fall-out and maintenance headaches from their work, and they don't have any vested interest in the quality of their work as long as it's good enough to pass review and get their payment check cut. In fact, poor quality is actually an opportunity to get paid twice since fixing the problems is a new project. Full-time permanent employees may not be as efficient as contractors, but on the other hand they've got a vested interest in making sure the system doesn't create any more problems than necessary because they know they're the ones who're going to have to clean up the messes. Long-term employees also have a better grasp of what's already involved in the current system, which translates directly into a better grasp of what the new system will need to do. They're less likely to miss major complications because they already have to deal with them.
Part of the problem with contractors is also the fact that large organizations like governments limit themselves to Tier 1 contractors. And there aren't a lot of those. So it rapidly becomes a situation where the Tier 1 contractors aren't really concerned about quality and results, because they know their customers will by policy refuse to consider any alternatives outside a small set and those others aren't any better about quality. If the government switches from contractor A to B, that means B can't take on another customer who takes their business to A (because A and B are the only Tier 1 firms and the customer can't consider anyone who isn't a Tier 1 firm) and it's a net wash for A.
Except that's because the vast majority of people are vaccinated against polio. That results in an almost negligible number of polio cases, which means nobody's exposed to it so they don't get it. It's called "herd immunity", and it's a direct benefit to your child. But it only works if the vast majority of people consider the consequences to your kid of them not being vaccinated. If the majority of people concentrate only on the risks to their own kid and concluded as you have, herd immunity evaporates and the number of polio cases will start to skyrocket as soon as there's any outbreak. And the risk of complications once your kid has contracted polio are, believe me, a lot worse than any risk from the vaccine, especially considering that there is no cure for polio once contracted.
The problem there is that the "studies" have been pretty thoroughly discredited. They're in the same category as a "study" that looks at a number of criminals, finds that the majority of them drank coffee within a day or two of committing their crimes, and concludes that drinking coffee causes you to become a criminal. The fallacy becomes obvious when you take a group of people who regularly drink coffee and another similar group who don't, look at how many in each group went on to become criminals and notice that there's no statistical difference between the two.
A more likely explanation is simply that a) most children get the vaccinations so most children who go on to develop autism will have gotten vaccinations, and b) children are likely to be diagnosed with autism shortly after a visit to the doctor (to, for instance, get vaccinated) who notices indications and recommends further testing resulting in the diagnosis.
There's always a risk. But the risks from getting the vaccine are dramatically lower than the risks from not getting it, and with recent outbreaks of these diseases the risk from not being vaccinated is going up sharply because of the increased risk of exposure. Even if you have a reaction to the vaccine, you're reacting to the disease agent so you'll have an even more severe reaction to actually being exposed to the disease and again your risk of exposure is going up due to an increased risk of exposure caused by people who refused vaccination.
Mumps, measles and rubella are in a completely different class than say the flu in both severity and ability to target a vaccine.
I find tablets closer to phones than laptops. They're large enough to use text-based menus and such like a desktop/laptop, but the screen size doesn't lend itself well to running many applications simultaneously. Two, maybe three is OK, but it's more natural to only have one thing in the foreground occupying the entire screen. The big difference is the pointer. A mouse pointer is a single pixel, and I can position it to within a couple of pixels using a mouse or trackpad. My fingertip is... a lot bigger than a single pixel, and anything smaller than about 1/8th inch square is annoying to target with any accuracy. Window frames become irritating to use to resize windows, and the title bar, menu bar, toolbars and such which can't be reduced below a certain minimum size and still be targetable accurately start to take up too great a portion of the screen real estate. It starts to feel like the UI's crowding out the actual application window. If you lay out the content like you would on a larger screen, it starts to feel cramped and uncomfortable and the scrolling to get to everything starts to be annoying. The simpler layout you'd use for a phone, with things separated into different panels that each occupy the whole screen and that can be switched between quickly, limited numbers of icons for actions, longer lists of actions that aren't needed all the time moved to pull-down menus where they're accessible but don't occupy screen real-estate when not actually needed, makes for a more comfortable application. And finally the big difference: the keyboard. One of the attractive features of a phone/tablet is that it doesn't need a keyboard. I can hold it in my hand and use it without anything extra hanging down, I don't need to find a stable surface to hold a keyboard while I type. And if you remove the keyboard and minimize typing, you end up with a completely different way of interacting with applications because you're avoiding a lot of text. I wouldn't, for instance, try typing this comment in on my phone's on-screen keyboard. Quick interactions like SMS or Twitter, yes. Long blocks of text like a word processor or a spreadsheet, no. And there's no way I'd play Everquest II on a phone or tablet. I simply couldn't fit the required UI elements into even a 10" screen at the sizes needed for fingertip pointing. They're cramped on a 17" monitor with a conventional mouse pointer where a 5-pixel-square button's feasible. Cutting screen real-estate in half while doubling the size of everything? No way, I wouldn't be able to see what was happening.
Phones are useful because of their form factor. The large screen of even a tablet makes for something you can't carry in your pocket or purse or conveniently on your belt. One of the requirements for a phone is that it can be conveniently carried in your pocket or purse or on your belt. So, not happening from that perspective. And that leads to the second problem: the compact, simple touch-based UIs that work well on the small form factor of a phone don't work well on the large screens of a desktop, and the more complex UIs that work well for desktops and laptops don't translate well to the ~5" display of a phone. Attempting to merge the two at that level is just not going to work, not due to any technical issues but simply because the requirements are different.
Now, the base OS underneath everything may merge. In fact, in the case of Android it already largely has. The main reason it hasn't completely isn't because the Android-specific functionality can't be included in the mainline Linux kernel, it's because Google hasn't done a good job of cleaning up their code to make it play nice in a codebase that isn't specific to Android. But the underlying OS isn't something most users ever see, and any merger there won't have a great impact on the user-visible aspect of things.
It is monitored more carefully. Notice that the backdoor was only introduced into the CVS copy, which wasn't the official copy used to create kernel releases. It never made it into the official copy in BitKeeper, because to get there it would've had to go through the official review and approval process that would've caught and rejected it. And without making it into the BitKeeper repository it never would've been used by any major distribution, only by developers and private distributions that pulled from the CVS copy because of objections to BitKeeper.
And today even that unofficial copy is gone. With the change to git I believe there aren't any secondary copies in other version-control systems except maybe private ones developers keep for whatever reason which wouldn't be able to feed changes back into the main repository without going through the review and approval process every submission has to go through.
Long and short, the Linux kernel repository's no more vulnerable than the internal repositories for Windows or the Oracle database system, and it's probably less vulnerable. Microsoft or Oracle's repositories will take commits from any random contractor that's been hired to work on the code, regardless of their background or history. The Linux repository... it may accept submissions from anyone, but the degree of review before approving the submission depends heavily on how well the project maintainers know the submitter. The first submissions from someone the maintainer doesn't know are going to be reviewed with a fine-toothed comb and a skeptical eye, and very few black-hats are going to be willing to spend years submitting high-quality code to build up enough of a reputation with the maintainer to be able to get code in with only a cursory review. It's the difference between a development team and a developer community.
I think the proper response would be to have an attorney draw up a letter saying "We appreciate your concern, and will comply with all legal demands. We will redirect that domain immediately upon receipt of a copy of the court judgement or order directing such. We await your prompt forwarding of said judgement or order. We have also initiated an inquiry with ICANN regarding the propriety of a third party demanding control of a domain without having obtained it through a valid registration, dispute resolution or court judgement or order.".
Slashdot Mirror
I haven't heard of any compiler that removes code just because it contains undefined behavior. All compilers I know of leave it in, and whether it misbehaves at run-time or not is... well, undefined. It may work just fine, eg. dereferencing a null pointer may just give you a block of zeroed-out read-only memory and what happens next depends on what you try to do with the dereferenced object. It may immediately crash with a memory access exception. Or it may cause all mounted filesystems to wipe and reformat themselves. But the code's still in the executable. I know compilers remove code that they've determined can't be executed, or where they've determined that the end state doesn't depend on the execution of the code, and that can cause program malfunctions (or sometimes cause programs to fail to malfunction, eg. an infinite loop in the code that didn't go into an infinite loop when the program ran because the compiler'd determined the code had no side-effects so it elided the entire loop).
I'd also note that I don't know any software developers who use the term "unstable code" as a technical term. That's a term used for plain old buggy code that doesn't behave consistently. And compilers are just fine with that kind of code, otherwise I wouldn't spend so much time tracking down and eradicating those bugs.
These aren't laws. They're private agreements between companies to limit poaching of employees. The only government interference here would be to make such agreements illegal, punishing companies that tried to limit the competition between them for the best employees.
The big problem is that we deregulated the cable and phone companies, but we didn't remove their monopoly agreements and we didn't enforce any regulations barring them from entering into non-compete agreements. So you end up with a situation like where I live, where Cox Cable isn't subject to regulation regarding rates, services and quality, etc. but at the same time no competing cable company's allowed in (because Cox still has an agreement with the city making them the only cable company allowed to run cable on the public right-of-way), the city attorney routinely enforces that agreement (taking legal action when one of the two cable companies in the area tries to provide service in an area assigned to the other, even when that other company isn't actually providing service in the affected area), and there's an agreement between Cox and Time-Warner (the other company in the area) not to offer service where the other's already providing it. End result: all the downsides of a monopoly combined with all the downsides of completely-unregulated services. They can do whatever they want with rates, there's no legal basis for challenging them, and there's no competitor you can switch to. To fix the problem we have to remove this pseudo-deregulation: either they're fully deregulated and not allowed to bar competition from entering the area, or they've got a monopoly on service and are subject to regulation as a public utility.
That's the thing, though: none of the news stories in my feed were posted by those major outlets. They're posted by other people I know, linking back to those major outlets. If News Corp. posts something, relatively few people will see it. It's only if those people repost it and other people are interested enough to want to re-repost it that it spreads and a lot of people see it. If that doesn't happen, odds on most people will never see it no matter what News Corp. does.
One of the biggest hurdles I always face as a software developer in private enterprise is upper management coming in and dictating not just what they want done but how it must be done and what technologies to use. Since they're not just unfamiliar with software development and technology in general but with the internal architecture and details of the systems the company has, the end result is the complete and utter mess you'd expect from say someone with no clue about cooking dictating how much of what ingredients a Cordon Bleu chef must use in a dish and how it must be cooked (as opposed to just telling him what dish you want and then getting out of the kitchen and letting him do the job you hired him for).
The pollsters missed it by the phrasing of their question. People aren't getting their news from Facebook. They're getting news from their friends and people they're following, who happen to be posting links to that news to Facebook. The difference is subtle but important. If someone goes "Oh, all we need to do is get our stories to appear on Facebook.", they're going to have their whole push fall on it's face because nobody's reading their articles. They'd need to get their articles in front of the people who lots of other people follow first, and make those articles interesting enough that those people post links to them for their followers to see. That's more complicated than just getting your story carried by a half-dozen major outlets.
I wouldn't add lag, I'd bucket it. 2 second windows. All trades in a 2-second window are collected by the exchange but not executed yet. When the window closes you take all the collected trades, shuffle them into a random order and execute them as if received in that order. Then wait for the next window to close and the next batch of trades to be processed.
Yes, this is going to thoroughly screw over anyone trying to take advantage of changes in prices over sub-2-second timeframes. The sensible reaction to that is to just not do that. Just like we don't spend hours cruising around repeatedly checking every gas station in town to see if they've changed prices during the day, because we know they usually only change prices once a day and you'll waste far more gas hunting for the rare exception than you'd ever save by it. Most people don't even drive all over looking for the absolute cheapest price, because they know they'll burn more on gas than they'll save getting a couple cents a gallon better price. They figure out which stations are usually the cheapest and just go there all the time, unless they happen to see an exceptional deal or notice another station routinely pricing below their usual one.
Literally. Microsoft touts all the capabilities built into Windows as advantages. The software and services to do all that are integrated into Windows. They aren't easy to remove. And the more things you have running, the more work the box has to do (even when it's idle, those services are still working in the background) and the more power it consumes. Android, OTOH, doesn't have all those services integrated into the OS, and it's a lot easier to remove unneeded services when they're separate components that you can just take out of the startup scripts.
After the state of IE10, I'm not surprised. I'm locked on IE9 because 10 isn't compatible with any of the webapps I need to access at work, ditto the Cisco SSL VPN software (I don't like browser-based VPNs, but I don't get to pick which VPN the company uses). At this point I can't afford to waste time experimenting with upgrading beyond 9, the compatibility issues are just too great for no perceptible gain (the best they could manage is to render Web pages as acceptably as 9 does, explain to me again why I'm wasting my time fighting to untangle compatibility issues to get back to where I started?).
The basic problem is that, while it sounds great in theory, in practice the transformations you want don't exist. If they did, you'd have software doing the job already and you wouldn't need to create it. Your business isn't going to go very far just doing the same thing everybody else is doing, is it? You need to be doing something they aren't. Which means, in this context, you need transformations that don't already exist (either because they haven't been written yet (ideally) or because the people who wrote them are keeping them confidential to keep you from copying what their business is doing (less than ideal)). So on top of your FBP team stringing components together, you're still going to need that expensive conventional development team to write the components for the FBP team to string together. You haven't saved much, in fact it's probably costing you more than just having the conventional dev team.
Plus, stringing components together isn't quite as simple as it sounds. Real-world systems usually depend on interaction and complex relationships between otherwise simple components. Keeping track of the synchronization between all those parts and keeping everything coordinated is usually the hard part. For instance, when creating an application to set up appointments the part where you take a set of existing appointment slots (some occupied, some free) and a set of one or more slots the customer would like ordered by preference and determine the best requested slot to put them in is easy. Picking up the current set of slots, putting them up on a Web page in a sensible way, letting the user select what ones work for them and set the order of preference, sending that information back to the server and, across this whole process, making sure that either nobody could alter the assigned appointments between the time you picked them up to display and the time the customer hit Submit and you started to sort out the assignment, that's nowhere near as simple. Doing this in a modern system with multiple servers where the submission may not go back to the server that handled the initial request, when you've got thousands of customers and hundreds of your users making, changing and cancelling appointments at the same time, ... can we say "highly non-trivial"? And it really doesn't fit the FBP model at all.
Even where things fit the model, it's rarely as simple as "just string them together". I work with software that fits that model. Well, it did. Once. Long ago. And then the business people said "Oh, but customer A wants it do to some other thing if it's a transaction for them.". Followed by "Well, we want to do X, unless C applies in which case we want to do Y.". "Oh, unless M was specified for the account, in which case do X even when C applies except where X set V to 7 we need it set to 14.". Lather rinse repeat for 10 years and the quick one-line summary version ran to 5 pages single-spaced. Until that is we tried to print it out and found things were nested so deep some lines were starting past the right-hand edge of standard letter paper, so it's more like 10 pages, legal-sized, in landscape mode.
Client certificates shouldn't change, at least not until they expire. And for authentication the site should be issuing the certificate so they can control expiration. But yes, there's supposed to be support for all this. I think the primary blame is Internet Explorer: it wouldn't support anything but Basic authentication and Windows-specific methods, and it wouldn't work correctly with any unsupported methods unless Basic was the first method. Meanwhile other browsers followed the spec and used the first (most-preferred) method that they supported, so if you wanted to support IE you forced every other browser to use nothing better than Basic (and you had to support IE). So everyone lost track of all those authentication methods other than Basic. Bleh.
Isn't this exactly what happens during SSL client certificate authentication? Modulo routing the response through a smartphone, that is.
So they have to weigh up the risks to their kids compared to the benefits for my kid?
No. They have to weigh the benefits to their kid vs. the risks to their kid. As do you. If you're short-sighted, you'll look only at the direct risks and benefits of the vaccination and your kid in isolation. But that ignores the fact that your kid isn't in isolation, he's going to be exposed to all the other kids around (and they're going to be exposed to him). If you take that short-sighted approach, and everybody else does too, then the risk to your kid increases, due to increased exposure to the disease and increased susceptibility to the disease, by far more than any risk of reaction to the vaccine that you've avoided.
If I "save" $20 but it costs me $200 to do so (that I wouldn't have had to spend if I weren't trying to save that $20), I haven't saved anything at all.
I'd also note that there's upsides to having people interested in doing the minimum. As my father put it about the ore-processing mill he was general foreman of, "I don't want the industrious, energetic twit who'll muck out the basement on Monday because the tanks overflowed, and muck out the basement on Tuesday because the tanks overflowed, and muck out the basement on Wednesday because the tanks overflowed... I want the lazy bum who'll figure out why the tanks keep overflowing and fix it so they don't so he doesn't have to muck out the basement every day. He gets to goof off half his shift, I get a mill that's running smoothly, the company ain't paying any more than they were fine with paying the energetic twit, I fail to see a problem here.".
Exactly.
http://arachnae.silverglass.org/rants/insurance-pool.html
There's a problem with that: the laws that say hospitals can't turn people away when they show up in the ER with a problem. And frankly there's very good reasons for those laws. We had a system where hospitals wouldn't treat you if you couldn't pay, and it resulted in major public-health problems that were costing the country (not the government, the country) huge amounts of money to deal with. So we changed the system.
NB: we had the same situation and the same problems when we had private fire departments. We changed that system for the same kind of reason: out-of-control fires caused by fire departments not responding because none of the houses they were getting paid to protect was on fire yet, and by the time they did respond half the block was burning and there was no way to control the blaze.
The reason for the mandate (and for the original single-payer system) is that currently the cost of health care for the uninsured is hidden in the "uncollectable debt" category in the hospital's accounts receivable. It's all the bills for ER visits and emergency care for people who can't pay. I was taught a basic rule back in high school business classes: you can't manage costs until you've got them laid out where you can see them. The idea was to get all health care being paid for and accounted for so we can see where the money's going and do something about the areas where it's costing more than it should. It was also to help with shifting the costs from expensive emergency care to much cheaper preventative care, the idea being that when people know they're covered by insurance they're more likely to go to the doctor before things get critical instead of putting it off and hoping they get better so they don't get nailed with a doctor's bill and ending up at the ER in critical condition. If you have no insurance the bill's going to be a killer either way so it makes sense to go for the chance to avoid it, whereas if you do have insurance the bill won't kill you either way so why wait and suffer more than you have to?
Part of the problem is the usual problems with large-scale IT projects: it's not until you're well into it that you really get a grasp of what's involved. Nothing government-specific there, that plagues all large IT projects in private industry. Part of the problem, though, lies exactly in the fact that contractors were used. Contractors are mercenaries. They're here to deliver this project, and once they get their paycheck they're on to other work. They won't be around to deal with the fall-out and maintenance headaches from their work, and they don't have any vested interest in the quality of their work as long as it's good enough to pass review and get their payment check cut. In fact, poor quality is actually an opportunity to get paid twice since fixing the problems is a new project. Full-time permanent employees may not be as efficient as contractors, but on the other hand they've got a vested interest in making sure the system doesn't create any more problems than necessary because they know they're the ones who're going to have to clean up the messes. Long-term employees also have a better grasp of what's already involved in the current system, which translates directly into a better grasp of what the new system will need to do. They're less likely to miss major complications because they already have to deal with them.
Part of the problem with contractors is also the fact that large organizations like governments limit themselves to Tier 1 contractors. And there aren't a lot of those. So it rapidly becomes a situation where the Tier 1 contractors aren't really concerned about quality and results, because they know their customers will by policy refuse to consider any alternatives outside a small set and those others aren't any better about quality. If the government switches from contractor A to B, that means B can't take on another customer who takes their business to A (because A and B are the only Tier 1 firms and the customer can't consider anyone who isn't a Tier 1 firm) and it's a net wash for A.
Except that's because the vast majority of people are vaccinated against polio. That results in an almost negligible number of polio cases, which means nobody's exposed to it so they don't get it. It's called "herd immunity", and it's a direct benefit to your child. But it only works if the vast majority of people consider the consequences to your kid of them not being vaccinated. If the majority of people concentrate only on the risks to their own kid and concluded as you have, herd immunity evaporates and the number of polio cases will start to skyrocket as soon as there's any outbreak. And the risk of complications once your kid has contracted polio are, believe me, a lot worse than any risk from the vaccine, especially considering that there is no cure for polio once contracted.
The problem there is that the "studies" have been pretty thoroughly discredited. They're in the same category as a "study" that looks at a number of criminals, finds that the majority of them drank coffee within a day or two of committing their crimes, and concludes that drinking coffee causes you to become a criminal. The fallacy becomes obvious when you take a group of people who regularly drink coffee and another similar group who don't, look at how many in each group went on to become criminals and notice that there's no statistical difference between the two.
A more likely explanation is simply that a) most children get the vaccinations so most children who go on to develop autism will have gotten vaccinations, and b) children are likely to be diagnosed with autism shortly after a visit to the doctor (to, for instance, get vaccinated) who notices indications and recommends further testing resulting in the diagnosis.
There's always a risk. But the risks from getting the vaccine are dramatically lower than the risks from not getting it, and with recent outbreaks of these diseases the risk from not being vaccinated is going up sharply because of the increased risk of exposure. Even if you have a reaction to the vaccine, you're reacting to the disease agent so you'll have an even more severe reaction to actually being exposed to the disease and again your risk of exposure is going up due to an increased risk of exposure caused by people who refused vaccination.
Mumps, measles and rubella are in a completely different class than say the flu in both severity and ability to target a vaccine.
I find tablets closer to phones than laptops. They're large enough to use text-based menus and such like a desktop/laptop, but the screen size doesn't lend itself well to running many applications simultaneously. Two, maybe three is OK, but it's more natural to only have one thing in the foreground occupying the entire screen. The big difference is the pointer. A mouse pointer is a single pixel, and I can position it to within a couple of pixels using a mouse or trackpad. My fingertip is... a lot bigger than a single pixel, and anything smaller than about 1/8th inch square is annoying to target with any accuracy. Window frames become irritating to use to resize windows, and the title bar, menu bar, toolbars and such which can't be reduced below a certain minimum size and still be targetable accurately start to take up too great a portion of the screen real estate. It starts to feel like the UI's crowding out the actual application window. If you lay out the content like you would on a larger screen, it starts to feel cramped and uncomfortable and the scrolling to get to everything starts to be annoying. The simpler layout you'd use for a phone, with things separated into different panels that each occupy the whole screen and that can be switched between quickly, limited numbers of icons for actions, longer lists of actions that aren't needed all the time moved to pull-down menus where they're accessible but don't occupy screen real-estate when not actually needed, makes for a more comfortable application. And finally the big difference: the keyboard. One of the attractive features of a phone/tablet is that it doesn't need a keyboard. I can hold it in my hand and use it without anything extra hanging down, I don't need to find a stable surface to hold a keyboard while I type. And if you remove the keyboard and minimize typing, you end up with a completely different way of interacting with applications because you're avoiding a lot of text. I wouldn't, for instance, try typing this comment in on my phone's on-screen keyboard. Quick interactions like SMS or Twitter, yes. Long blocks of text like a word processor or a spreadsheet, no. And there's no way I'd play Everquest II on a phone or tablet. I simply couldn't fit the required UI elements into even a 10" screen at the sizes needed for fingertip pointing. They're cramped on a 17" monitor with a conventional mouse pointer where a 5-pixel-square button's feasible. Cutting screen real-estate in half while doubling the size of everything? No way, I wouldn't be able to see what was happening.
Phones are useful because of their form factor. The large screen of even a tablet makes for something you can't carry in your pocket or purse or conveniently on your belt. One of the requirements for a phone is that it can be conveniently carried in your pocket or purse or on your belt. So, not happening from that perspective. And that leads to the second problem: the compact, simple touch-based UIs that work well on the small form factor of a phone don't work well on the large screens of a desktop, and the more complex UIs that work well for desktops and laptops don't translate well to the ~5" display of a phone. Attempting to merge the two at that level is just not going to work, not due to any technical issues but simply because the requirements are different.
Now, the base OS underneath everything may merge. In fact, in the case of Android it already largely has. The main reason it hasn't completely isn't because the Android-specific functionality can't be included in the mainline Linux kernel, it's because Google hasn't done a good job of cleaning up their code to make it play nice in a codebase that isn't specific to Android. But the underlying OS isn't something most users ever see, and any merger there won't have a great impact on the user-visible aspect of things.
It is monitored more carefully. Notice that the backdoor was only introduced into the CVS copy, which wasn't the official copy used to create kernel releases. It never made it into the official copy in BitKeeper, because to get there it would've had to go through the official review and approval process that would've caught and rejected it. And without making it into the BitKeeper repository it never would've been used by any major distribution, only by developers and private distributions that pulled from the CVS copy because of objections to BitKeeper.
And today even that unofficial copy is gone. With the change to git I believe there aren't any secondary copies in other version-control systems except maybe private ones developers keep for whatever reason which wouldn't be able to feed changes back into the main repository without going through the review and approval process every submission has to go through.
Long and short, the Linux kernel repository's no more vulnerable than the internal repositories for Windows or the Oracle database system, and it's probably less vulnerable. Microsoft or Oracle's repositories will take commits from any random contractor that's been hired to work on the code, regardless of their background or history. The Linux repository... it may accept submissions from anyone, but the degree of review before approving the submission depends heavily on how well the project maintainers know the submitter. The first submissions from someone the maintainer doesn't know are going to be reviewed with a fine-toothed comb and a skeptical eye, and very few black-hats are going to be willing to spend years submitting high-quality code to build up enough of a reputation with the maintainer to be able to get code in with only a cursory review. It's the difference between a development team and a developer community.
I think the proper response would be to have an attorney draw up a letter saying "We appreciate your concern, and will comply with all legal demands. We will redirect that domain immediately upon receipt of a copy of the court judgement or order directing such. We await your prompt forwarding of said judgement or order. We have also initiated an inquiry with ICANN regarding the propriety of a third party demanding control of a domain without having obtained it through a valid registration, dispute resolution or court judgement or order.".