I guess my question would be, why shouldn't it be your subscribers who pay? They're the ones requesting the data. What you're saying is the equivalent of "I run a mail store that does PO boxes, UPS shipping and the like. 85% of my customers order a lot from Amazon. I'm not sure it's my customers who should pay for my handling all those UPS deliveries, since it'll cost them too much if I have to expand my delivery dock and storeroom.". If someone tried to make that argument, that Amazon should pay for them to expand their business so their customers wouldn't have to, we'd laugh at the idea. And the fact that those customers are also paying for Amazon Prime memberships would be just irrelevant to the argument. It's the customers ordering the shipments, and it's the customers paying you to handle their mail and UPS shipments for them. Even in the case where people who weren't your customers were having stuff sent to you for pickup, you wouldn't normally be allowed to bill the company who sent the packages. You'd either make whoever ordered the shipment pay before he could get his packages, or you'd refuse to accept the packages and let the shipper and the shipping company sort delivery out with their customer.
What's going on here isn't about Netflix, it's about bandwidth. It boils down to: the Netflix HD service requires a lot of bandwidth to the end user, Netflix is setting it up so the ISPs have access to the high-bandwidth external connection needed to deliver the streams to their networks, now the ISPs are trying to figure out how to allocate costs for the bandwidth on their networks to deliver those streams to the users. And right now I don't see a problem. My ISP has no regulatory problem whatsoever charging different prices based on the bandwidth available to me. So, do that. If the user wants the extra bandwidth needed to deliver the HD video stream and still be able to do anything else without mucking up both, he's going to have to buy the higher-bandwidth Premium service instead of Standard. If he doesn't, he's going to have to live with HD streams that stutter and jump and Web sites that load slowly or fail to load completely while the video's streaming because the ISP's throttling his traffic to the rate he's paying for. End of cost-allocation problem.
And I'd note that it's not Netflix demanding bandwidth on the ISP's network. It's the ISP's own users asking for the bandwidth. Netflix doesn't send a single packet to an ISP until a user of that ISP connects to Netflix and asks them to start sending data. And the ISP has explicitly sold their service to their users as a way to do that, to access sites and services on the Internet. That's why they're called Internet Service Providers: the service they offer is providing access to the Internet. If their users are requesting more data than the ISP's network can handle, seems to me that's an issue between the ISP and it's customers. I'm sure the ISP would rather side-step the issue, but I don't see where that obliges anybody else to help them. If I'm ordering things delivered to the apartment complex I live in and the complex has a gate that the delivery trucks won't fit through, that's not the delivery company's or the store's problem. That's between me and the complex to deal with.
1. System. time_t needs to expand, probably to 64 bits to match the natural integer size on a 64-bit system. That may already have happened on some 64-bit OSes.
2. Libraries. You'll need to get updated versions that handle the problem. How they do it's up to the vendor. The worst cases will be libraries that appear to work in YMD or Julian day numbers externally but use time_t internally, those need updating but it won't be obvious they do.
3. Internal calculations in the code. Anything that works directly in YMD or JD shouldn't have a problem. Anything that deals with time_t will need checked to make sure it's 64-bit-clean, but that's a subset of checking all the math in your code to make sure it cleanly handles going to 64-bit integers. Spots where fixing this is hard should be uncommon.
4. External formats. Ones that store times as YMD (probably in a string form) or JD (string or integer) shouldn't have a problem. Ones that store the time_t value itself as an integer converted to an ASCII string should only have a problem if there's not enough characters in the field to handle a larger number of digits, and even then only when the value hits 10 billion seconds from epoch. Ones where the actual 4-byte time_t binary value is stored are the ones that'll have problems, since there's no good fix there that doesn't involve changing the format to use a larger field with all the headaches that go along with that.
Most of the code I'm responsible for falls into #3, making sure the arithmetic is all 64-bit-clean. There's a minority of database-code-related clean-up, but mostly the conversions there are within the database and it's the database vendor's problem (or it'll be the more generic problem of converting to another database and vendor). External storage and data formats are almost a non-issue, almost universally if they're concerned with dates they use a YMD string format and don't deal with time at all. Most of the places where there's an actual time value, eg. timestamp fields, it's a string of some sort.
The biggest worry I have is with NTP, which uses 32-bit unsigned seconds since 1 Jan 1900 in the packets. It's so pervasive for setting time that it'll be a major source of headaches, but at the same time nothing except the NTP software itself is affected by the packet format and there's a nice version number at a fixed position at the start of the packet so I can think of several ways off-hand of dealing with the problem (if it hasn't already been dealt with).
In a setup like this you wouldn't put the RAM on the CPU card. It'd go on the backplane interconnect, independent of the CPU. Think the PDP-11 Unibus or the VAX-11 Synchronous Backplane Interconnect, which are where I first encountered the concept of a backplane and independent CPU, memory, co-processor and I/O processor modules. I doubt they originated there, though, my guess is the concept goes back to the IBM mainframes of the 60s. It was an amusing cycle: external modules would migrate onto the CPU board for performance reasons, then the on-board interconnect would mutate into a new backplane and everything would migrate out to external modules for maintenance and upgradability reasons, and then the cycle would repeat.
You're over-loading the problem. You do IT work, so stop and think a minute about how many problems you've stated here:
1. A format for holding the patient's complete medical record for permanent storage and transfer between systems.
2. Formats for sending various types of requests between systems, eg. sending a prescription from the doctor to the pharmacy.
3. Internal working storage that holds the data a particular system needs in a form that's easy for that system to handle.
Now, why would I use the same format for all 3? The third wouldn't be XML at all, it'd be a database schema probably. The second would be specific to the request at hand, I wouldn't use the same format to send over a prescription as I'd use to send the bill to the insurance provider. The first would be the one at issue here, and would contain both less and more information than the other formats (I wouldn't, for instance, put detailed billing information for every item in the medical record, although I might include a record for the insurance provider(s) and when the patient was covered by them).
And I'm usually on the other end of your EMR problem, being the guy who has to write the client software that submits requests. Half the time my problem is ambiguous documentation, much of the other half it's legacy code I have to match. Seriously. I've had to write code that fails to follow spec because it's required to successfully talk to a simulator that fails to follow spec, and the simulator team won't fix it because they've got no resources for the job and it works fine with their existing software.
You want to make electronic health records easier for consumers?
1. Set up a standard XML format for records and mandate that all providers must give consumers access to the data in that standard format (other formats are allowed, but the standard format's required). That'd give services and software at least one format they can target for import/export that the patient's guaranteed to be able to get. Make sure the format inclues a "Notes" element that's free-form text, so providers can include stuff that won't fit anywhere else, but require that if the format provides an element for the information that element must be populated with that information (ie. no putting everything in the "Notes" element and leaving the actual XML unpopulated).
2. Mandate that the patient's record be complete. When I go to get my electronic records from my doctor's office, there's two major problems. First, they only include so many records and then cut the record off. I want a copy of all my records that they have, not just the last year's. Second, they don't include certain "sensitive" records. Again, I want a copy of all my records. I'm the patient, by definition I know or should have been told everything in that file. If there's anything in that record that it'd be a problem for me to see, then the problem is that the provider is concealing information from me. If it'd be confusing, the provider should have already discussed it with me so I won't be confused. Omitting sensitive or irrelevant records from a copy sent to another party would be OK but the patient's copy should have complete information for every record the provider has for the patient, without exception or limitation.
Frankly as a patient I'd love a single standard format I could get and maintain myself, so when I went to a new doctor I could just hand them a USB drive or SD card with my complete record on it. It'd make it easier for me too, no more struggling to remember phone numbers of doctors I saw years ago and no more dealing with a doctor I saw ages ago having moved his office and my new doctor can't reach him to get the records.
Except that the reason so few get hit with the zero-day stuff is because of all the people running AV software that WILL detect it and report it so it can get added to the lists. If everybody were running MSE, the majority WOULD be getting hit with zero-day stuff because there wouldn't be any alerts for it until days or weeks after an infection started spreading. In infection-disease circles it's called "herd immunity": if a sufficiently large portion of the population is immune to a disease (through vaccination or natural immunity), those who aren't are protected simply by never coming in contact with any infected individuals. But as soon as the fraction of immune/protected individuals drops below that critical point, the protection rapidly disappears. And it's not a linear decline, it's almost an exponential drop-off in protection once you drop below the critical level. That's why, BTW, we're seeing outbreaks of diseases today that haven't been common since the 50s or earlier. Vaccinations virtually wiped them out mid-century, but now we've got generations who didn't get as consistently vaccinated because "That's all been wiped out, and anyway everyone's vaccinated so who's going to give it to my kid?". Herd immunity breaks down and hey presto, clusters of diseases that were supposed to have been wiped out start popping up.
Though, how often have we seen the statement "That's only a proof-of-concept, there's no need to worry about it because we haven't seen it in the wild." followed within weeks by announcements of that same malware appearing in the wild (and usually on a large scale)? I've long since filed "It's only a proof of concept." right alongside "What could possibly go wrong?" as a virtual guarantee that Murphy'll be visiting shortly.
Yep, but if they continue to call knowing that the debtor isn't there, they're in violation of various sections of the FDCPA. It's not usually hard to track the phone number back to a collections agency, they're not real good at hiding themselves. And once I know that, I respond to their question with "Is this $NAMEOFCOLLECTIONAGENCY?". That puts them in a bind and how they answer doesn't change the substance of my next statement, only it's phrasing: "The person XXXXX you are trying to contact does not live here and can't be contacted through this number. If you continue to call this number I will consider it harassment and a violation of the FDCPA.". Then I hang up. If I'm really annoyed and anticipating actually doing anything to them, I'd print out a quick little letter and spend a few bucks on registered mail, return receipt requested to their office. But if they really aren't calling for me or anyone here, usually just being firm gets them to stop, because they don't want the hassle and expense of sending someone to small-claims court and they really don't want the hassle of dealing with a default judgement if they don't. Judges may be unsympathetic to people trying to get free money via FDCPA/TCPA complaints, but it's easy to frame the complaint instead as an aggrieved uninvolved party who just wants the phone calls to stop who's faced with a company that just won't accept the truth.
If you're female, filing the harassing-calls paperwork might produce interesting results. Female getting calls at all hours, faked caller ID information, dead air (robodialer trying to find an agent to hand the call to) or a male who won't identify themselves (agent instructed not to give out information), you're getting creeped out by it (you probably are), that should get the incident routed over to Vice as a potential stalker.
That would be incorrect. See Section 806 of the FDCPA, 15 USC 1692d, which begins "A debt collector may not engage in any conduct the natural consequence of which is to harass, oppress, or abuse any person in connection with the collection of a debt.". There's also a kicker in section 805(b), which prohibits a debt collection from communicating with any third party without the consumer's consent except for the specific purposes described in section 804 on locating the actual consumer. So yes, the FDCPA provides remedies and protections for people other than the consumer.
Absolutely nothing. In fact, I think they've already found ways to break out of most of the hypervisors out there and gain access to the host machine from inside a VM. The only exceptions I can think of are the IBM mainframe hypervisors, and those have the dual advantages of a) decades of work finding and removing bugs and b) hardware that was designed to run the hypervisor and has special support for isolating the hypervisor from the virtual machines.
Bear in mind that for cloud applications you actually need to be worried about the reverse: protecting your application from the hypervisor breaking into it. The worst incursions won't be from other applications breaking out of their VMs, it'll be incursions from the cloud provider's own internal network (from conventionally-infected machines) infiltrating the host machines' hypervisor software and from there reaching down to infect hosted applications.
The safest thing to do at this point is just assume that Java is always going to be vulnerable.
That's not specific to Java, it applies to all software that's downloaded from an outside source and run on your local machine. That means Adobe Reader (PDF is simply a wrapper for a program written in Postscript), Flash (ditto, written in a special programming language) and even Javascript. It even includes downloaded TrueType fonts (the font hinting program they can include is just that, an executable program). Don't dismiss them just because they're sandboxed. Java was sandboxed, that didn't stop this vulnerability. Sandboxes are software and software has bugs in it, always. The only question is the number and severity of the bugs. The simpler the software, the fewer bugs there tend to be because there's fewer places for them to hide. Their favorite hiding place is in unexpected interactions between different parts of a piece of software, or between the software and the system it runs in, and simpler software has fewer and simpler interactions that're easier to get right.
This even applies to software you buy from a vendor. The difference is that with bought software you tend to download it only a few times and always directly from the source. Contrast this with the Web, where you're downloading multiple pieces of software on virtually every Web page you hit with no idea where they're coming from (and, in the case of advertising networks, the place you download them from may not even know who or where they're coming from).
True, but then by going over to someone else I'm interrupting them just as much as people coming to me interrupts me. And much of the stuff can be handled better via e-mail, which leaves a nice neat paper trail of information that I can file and refer back to and is a lot less disruptive if properly used. Don't underestimate the value of that paper trail. A record of why you came to a particular decision about how to do things is more valuable than a simple description of the decision. Things will change over time, and you can't know if the reasoning behind a decision's still valid if you don't have a record of what that reasoning was. Having the conversation in e-mail automatically creates that record (assuming people file the e-mails, which I do). There's also IM and VoIP and desktop sharing, and it's amazing how effective those can be (especially when combined with webcams so you can see who you're talking to). I can reserve face-to-face for really critical issues.
As for group areas, I'd say that simply having several meeting rooms with network access should suffice. I've found it rare that I needed to be actually working in a group for any length of time, more often it's sit down as a group to bat issues around and come up with plans, then divide up and get working with individual conversations when needed. And one big bullpen area, suitable sound-isolated from the office area, where you can sit down for truly large meetings or for things like full deployment tests where for an afternoon you really are leaning over each other's shoulders to help sort out problems.
You want me to be productive as a developer? OK, here's what I need to do that:
A comfortable workspace. Give me a good solid desk with drawers and shelving to store reference and work materials. A phone with a headset so I can hold a conversation and work on the computer at the same time. A comfortable chair. Not one of the $99 specials from Office Depot, something high-end that's rated for 8 hours of continuous use. If what you're providing for an office workspace isn't at least as good as what I can afford personally at home, there's probably something wrong.
A good computer. It needs to have enough CPU horsepower and enough memory and disk for the software you expect me to be using. And it needs to be better than the minimum spec, I can't be productive when my tools are barely limping along. Good monitors too, and more than one. I'm going to regularly be pulling up digital reference materials and I'll have a lot of work on my screen, I need the screen real-estate to have all of it available without constantly having to shuffle windows to the top. You want to understand why, try doing your work with only one sheet of paper visible at a time and if you need to refer to 2 reports at once you have to lay one on top, read it, pull the other one out and lay it on top to read it, lather rinse repeat. If you don't think you can be productive working that way, why should you expect me to be?
Give me the reference materials and tools. If you expect me to work with tools or systems, give me all the documentation on them. It doesn't have to be physical, but it has to be available and up-to-date. If you want me to work on something, give me the tools to work on and with it. IDEs, editors, file comparison tools, merge utilities, it's possible to not skimp without going overboard. If you want me to work on software that accesses a database, give me a database client and access to those databases and a personal database I can play with to test things before I break the world for everybody else. If you want me to work on a system, set it up so I have my own installation I can put changes into to test. And for crying out loud, give me documentation on how to set it up and configure it and use it so I'm not completely lost going in.
Give me the ability to work uninterrupted. I know open-plan offices are all the rage, but you're expecting me to do work that requires high concentration for hours at a time. I can't do that with every conversation in the office distracting me, or everybody coming over randomly with questions or conversation. Same for phone calls. People should not be calling developers directly unless the developer's asked them to. If you need to, hire a receptionist to field calls and route them where they need to go (as opposed to where the caller wants them to go).
Let me work on my projects. I have a priority list. I use it to decide what things I should focus on now. But it doesn't do me any good if the priorities are constantly changing. I know, I know, the old saw about responding to business needs. Think a minute: maybe the problem isn't that I need to respond, but that business needs to start thinking more than a few days ahead? If requirements for a new project are constantly changing, perhaps you just don't have a good enough idea of what you want to start actual work on it yet. One of the worst ways to kill my productivity is to give me just enough time to get a handle on a project and start work, then make me drop it and start on a completely different project, and keep doing this repeatedly. When you pull me away from project A to work on B, it costs project A more than just the time I was working on B. The distraction will make me forget some of the details of what I was working on for A so when I get back to it I won't be able to just pick up where I left off, I'll have to backtrack and spend time remembering my train of thought and reconstructing all those details before I can start working again. So try to settle the priority lists down so they're not changing on a daily b
I always considered readability and maintainability to be implicit technical requirements for any project. Simply put, new people will have to read and understand the code, and you will have to maintain and enhance the code. The code therefore needs to be amenable to being read and maintained. If it isn't, you end up wasting time and resources fighting the code that could've been spent delivering new features.
Case in point: a data-acquisition component I work on. When I started it supported 3 data sources, and supported only straight-TCP network sources using source-specific protocols over a socket. It had a lot of problems, a lot of places where code for a common task had to be duplicated in the implementation of all 3 data sources and a lot of places where code was intertwined that didn't really have any commonality, but with such a small number of data sources it was livable-with. We rarely added data sources, so there wasn't a lot of payoff for improving the code.
But then after I started working on it, things changed. Instead of 1 new data source every 4-5 years, we got 3 new sources in one year. And a new type, based on HTTP POST rather than messages over a simple TCP socket. Worse, we were told that this kind of pace was going to continue, and that we were going to get more types of data sources like ones pulling from SOAP services (HTTP can still be thought of as text requests and responses, but SOAP ends up looking like actual objects and not simple text strings). It was taking too long to do simple things with the code, and we were spending too much time tracking down and fixing bugs caused by new changes breaking old code that we didn't realize was affected. So I pretty much twisted arms until I got the OK to rewrite it based on what I knew we were going to be asked to do.
The payoff? Cut the time to add a new type of data source in half. Cut the time to add a new data source of an existing type by 80%. Virtually eliminated a class of recurring bugs where we'd fixed the code in one data source but not in others because we missed multiple instances of common code. Cut the number of bugs where new changes broke existing data sources by 90+%. Took a class of request of the "This neat new feature for data source X? Can you add it to all the others?" sort and turned it from a days-long exercise in locating and modifying multiple copies of code to a quick exercise in passing the correct arguments to common functions.
The only way I'd accept the "only disclose to the owner" condition is if it included a time limit within which the owner must either fix the vulnerability or disclose the vulnerability to the public, and if the owner fails to meet the limit the confidentiality is lifted and the hacker is free to disclose the vulnerability himself. If software makers want their mistakes kept confidential then the cost is a binding commitment to fixing those mistakes, and the penalty for failing to meet their commitment is that the hackers are freed from theirs.
That's an odd position to take given the actual budget numbers. I collected some of them here. What's odd is that every Republican President since 1976 has presided over a larger year-to-year increase in both the debt and the deficit than the worst Democratic President (Carter). And you can't blame it on a Democratic Congress: the majority of of Clinton's term saw a Republican Congress, as did the majority of Bush Jr.'s terms, yet Clinton's terms saw net reductions in the deficit and rate of growth of the debt while Bush Jr. oversaw net increases in both. And Obama has had a Democratic Senate since he was elected and a Democrat-controlled House for half his term, yet again net reductions in the deficit and rate of growth of the debt. The numbers... appear to add up to exactly the opposite of your position.
Nope. All you need is a number of devices greater than the number required to cause a problem. We have evidence that it's greater than 2-3. Can you present any evidence that it's always going to be greater than the number of seats on the airliner in question?
Because with the flight crew you're dealing with a limited number of devices and a limited amount of potential RF interference. Extend that to passengers and you have not just 1-2 but possibly a hundred or more devices simultaneously, and that can have a drastically different effect on the avionics.
If I pour a gallon of water into a standard rowboat on a lake, it's not going to sink. If I pour another gallon of water in, it's still not going to sink. 2 gallons just isn't enough to cause a problem. even 5-6 gallons isn't. But if I pour a couple hundred gallons in, it's going to sink. I can't go "Well, adding another gallon didn't make a difference, so adding another gallon more won't either." indefinitely. At some point you reach the straw that broke the camel's back. When reaching that point can potentially get 200 or so people killed as the plane stops flying, I'd really rather we avoided going there.
Think about it a moment. The ultimate piece of malware would be one that can make your computer run software of someone else's choice, prevent you from running software other than the malware, and block you from removing the malware from the system or preventing it from running. Every piece of malware out there tries to do this, with varying degrees of success. Look at the malware that tries to disable anti-virus/anti-malware software.
Now, Restricted Boot would give someone else control over what software could boot on the machine, and prevent you from changing that list of authorized software. You cannot authorize software you want to run to run, nor can you remove authorization from software you do not want to run. You can't influence what runs at boot, you can't alter it's operation. In short, you've bought into every malware author's wet dream: a system where they can do anything they want and the user can't do a thing about it.
And if you think "Oh, but all the system software would be signed by Microsoft, so how would the malware authors get the keys to authorize their software?", think about this: Microsoft certificates have already been compromised. The bad guys have already gotten access to what they need to sign software with legitimate Microsoft keys. The certificates used by the Flame malware were only some of the most recent. And I'd note this older bulletin describing a situation where Verisign issued legitimate certificates issued to Microsoft to black-hats with no association with Microsoft. The bad guys obtaining the private keys to sign software isn't a theoretical discussion, it's already actually happened.
The right answer: "I screwed up. I accept responsibility for screwing up, and I'm going to take care not to screw up in the future (and especially not in the same way).".
This isn't backwards compatibility. It's the same basic rule we have to follow where I work: you DO NOT EVER make unannounced/unplanned changes that break the way other modules interact with yours. Period, end of line. Break that rule with any sort of regularity and you'll be looking for a job. If you need to make a change like that, it's on you to justify why and then to coordinate with everyone else to make sure everything that needs changed gets changed. It's not a hard rule to understand or to follow. If you can't, you have no business messing with an operating system kernel.
Which still leaves the unsafe condition of cars speeding through a construction zone. Unsafe not just for workers, but for the occupants of the cars if, for instance, there's a sudden lane position shift to avoid a solid obstacle, one that's safe at 25mph but unnavigable at 65mph. With a driver in the car, he can recognize that the car's failed to recognize and adapt to the situation, override the car and slow down to a safe speed.
That's also, BTW, why all those "silly" laws from the early days of cars aren't in fact silly. The guy walking ahead with the lantern or the limiting of the car's speed to that of a horse weren't for the car. They were for everybody else on the road who weren't used to cars (them being new and not commonly encountered), to give them warning and to keep them from having to face something coming at them unexpectedly and far faster than they were prepared to react to.
Sure, you can do it. Now, describe to me how you do it. Precisely. In detail. Clearly and simply enough that I can give a trained monkey your instructions and it can successfully do the same thing. Now, re-write those instructions so they still work when the monkey's trainer is reading over it's shoulder and going off and altering conditions with the express intention of making your instructions fail to work, because we all know Murphy's always out there just waiting for his chance and when you're talking 2 tons of steel moving at 65mph the failure modes tend to involve the emergency room and/or the morgue.
Yes, I'm being cynical and pessimistic here. I've spent too many years watching people answer my pointing out thread-unsafe constructs with "That's not a problem, it's a million to one we'll see that happen.". Yeah, and you're executing that stretch of code how many million times a minute? As I put it, "I'm one in a million? Gods, that means there's 310 more just like me in the United States ALONE, let's not even count the rest of the world...". Or, to a vendor, "Sorry, but 99.99% uptime means we can expect at least one of our stations to be down every day. That's unacceptable.".
Dirt, grime, frost, the idjit behind with the HID lamps on hi-beam making so much glare off the reflective surface of the sign that it's washing out the lettering, poor positioning so the sign's blocked from view until you're almost on it so the camera only gets a frame or two and then it's past the sign (seen that in construction zones, and the cops and the judges will cut you no slack for it), someone just plain forgot to put up the signs (also seen that, ditto on cutting you any slack)...
This, BTW, is why software has so many problems including so many security vulnerabilities: people go assuming the world's basically nice except for the occasional failure. But to make things reliable you have to assume the opposite, that the world's out to get you and is actively working to make things go wrong in the worst possible way at the worst possible time and you'll need to be prepared to handle it. In software development it's called "programming Satan's computer", and it's the only way to create highly-reliable software.
Slashdot Mirror
I guess my question would be, why shouldn't it be your subscribers who pay? They're the ones requesting the data. What you're saying is the equivalent of "I run a mail store that does PO boxes, UPS shipping and the like. 85% of my customers order a lot from Amazon. I'm not sure it's my customers who should pay for my handling all those UPS deliveries, since it'll cost them too much if I have to expand my delivery dock and storeroom.". If someone tried to make that argument, that Amazon should pay for them to expand their business so their customers wouldn't have to, we'd laugh at the idea. And the fact that those customers are also paying for Amazon Prime memberships would be just irrelevant to the argument. It's the customers ordering the shipments, and it's the customers paying you to handle their mail and UPS shipments for them. Even in the case where people who weren't your customers were having stuff sent to you for pickup, you wouldn't normally be allowed to bill the company who sent the packages. You'd either make whoever ordered the shipment pay before he could get his packages, or you'd refuse to accept the packages and let the shipper and the shipping company sort delivery out with their customer.
What's going on here isn't about Netflix, it's about bandwidth. It boils down to: the Netflix HD service requires a lot of bandwidth to the end user, Netflix is setting it up so the ISPs have access to the high-bandwidth external connection needed to deliver the streams to their networks, now the ISPs are trying to figure out how to allocate costs for the bandwidth on their networks to deliver those streams to the users. And right now I don't see a problem. My ISP has no regulatory problem whatsoever charging different prices based on the bandwidth available to me. So, do that. If the user wants the extra bandwidth needed to deliver the HD video stream and still be able to do anything else without mucking up both, he's going to have to buy the higher-bandwidth Premium service instead of Standard. If he doesn't, he's going to have to live with HD streams that stutter and jump and Web sites that load slowly or fail to load completely while the video's streaming because the ISP's throttling his traffic to the rate he's paying for. End of cost-allocation problem.
And I'd note that it's not Netflix demanding bandwidth on the ISP's network. It's the ISP's own users asking for the bandwidth. Netflix doesn't send a single packet to an ISP until a user of that ISP connects to Netflix and asks them to start sending data. And the ISP has explicitly sold their service to their users as a way to do that, to access sites and services on the Internet. That's why they're called Internet Service Providers: the service they offer is providing access to the Internet. If their users are requesting more data than the ISP's network can handle, seems to me that's an issue between the ISP and it's customers. I'm sure the ISP would rather side-step the issue, but I don't see where that obliges anybody else to help them. If I'm ordering things delivered to the apartment complex I live in and the complex has a gate that the delivery trucks won't fit through, that's not the delivery company's or the store's problem. That's between me and the complex to deal with.
It really boils down to 4 individual problems:
1. System. time_t needs to expand, probably to 64 bits to match the natural integer size on a 64-bit system. That may already have happened on some 64-bit OSes.
2. Libraries. You'll need to get updated versions that handle the problem. How they do it's up to the vendor. The worst cases will be libraries that appear to work in YMD or Julian day numbers externally but use time_t internally, those need updating but it won't be obvious they do.
3. Internal calculations in the code. Anything that works directly in YMD or JD shouldn't have a problem. Anything that deals with time_t will need checked to make sure it's 64-bit-clean, but that's a subset of checking all the math in your code to make sure it cleanly handles going to 64-bit integers. Spots where fixing this is hard should be uncommon.
4. External formats. Ones that store times as YMD (probably in a string form) or JD (string or integer) shouldn't have a problem. Ones that store the time_t value itself as an integer converted to an ASCII string should only have a problem if there's not enough characters in the field to handle a larger number of digits, and even then only when the value hits 10 billion seconds from epoch. Ones where the actual 4-byte time_t binary value is stored are the ones that'll have problems, since there's no good fix there that doesn't involve changing the format to use a larger field with all the headaches that go along with that.
Most of the code I'm responsible for falls into #3, making sure the arithmetic is all 64-bit-clean. There's a minority of database-code-related clean-up, but mostly the conversions there are within the database and it's the database vendor's problem (or it'll be the more generic problem of converting to another database and vendor). External storage and data formats are almost a non-issue, almost universally if they're concerned with dates they use a YMD string format and don't deal with time at all. Most of the places where there's an actual time value, eg. timestamp fields, it's a string of some sort.
The biggest worry I have is with NTP, which uses 32-bit unsigned seconds since 1 Jan 1900 in the packets. It's so pervasive for setting time that it'll be a major source of headaches, but at the same time nothing except the NTP software itself is affected by the packet format and there's a nice version number at a fixed position at the start of the packet so I can think of several ways off-hand of dealing with the problem (if it hasn't already been dealt with).
In a setup like this you wouldn't put the RAM on the CPU card. It'd go on the backplane interconnect, independent of the CPU. Think the PDP-11 Unibus or the VAX-11 Synchronous Backplane Interconnect, which are where I first encountered the concept of a backplane and independent CPU, memory, co-processor and I/O processor modules. I doubt they originated there, though, my guess is the concept goes back to the IBM mainframes of the 60s. It was an amusing cycle: external modules would migrate onto the CPU board for performance reasons, then the on-board interconnect would mutate into a new backplane and everything would migrate out to external modules for maintenance and upgradability reasons, and then the cycle would repeat.
You're over-loading the problem. You do IT work, so stop and think a minute about how many problems you've stated here:
1. A format for holding the patient's complete medical record for permanent storage and transfer between systems.
2. Formats for sending various types of requests between systems, eg. sending a prescription from the doctor to the pharmacy.
3. Internal working storage that holds the data a particular system needs in a form that's easy for that system to handle.
Now, why would I use the same format for all 3? The third wouldn't be XML at all, it'd be a database schema probably. The second would be specific to the request at hand, I wouldn't use the same format to send over a prescription as I'd use to send the bill to the insurance provider. The first would be the one at issue here, and would contain both less and more information than the other formats (I wouldn't, for instance, put detailed billing information for every item in the medical record, although I might include a record for the insurance provider(s) and when the patient was covered by them).
And I'm usually on the other end of your EMR problem, being the guy who has to write the client software that submits requests. Half the time my problem is ambiguous documentation, much of the other half it's legacy code I have to match. Seriously. I've had to write code that fails to follow spec because it's required to successfully talk to a simulator that fails to follow spec, and the simulator team won't fix it because they've got no resources for the job and it works fine with their existing software.
You want to make electronic health records easier for consumers?
1. Set up a standard XML format for records and mandate that all providers must give consumers access to the data in that standard format (other formats are allowed, but the standard format's required). That'd give services and software at least one format they can target for import/export that the patient's guaranteed to be able to get. Make sure the format inclues a "Notes" element that's free-form text, so providers can include stuff that won't fit anywhere else, but require that if the format provides an element for the information that element must be populated with that information (ie. no putting everything in the "Notes" element and leaving the actual XML unpopulated).
2. Mandate that the patient's record be complete. When I go to get my electronic records from my doctor's office, there's two major problems. First, they only include so many records and then cut the record off. I want a copy of all my records that they have, not just the last year's. Second, they don't include certain "sensitive" records. Again, I want a copy of all my records. I'm the patient, by definition I know or should have been told everything in that file. If there's anything in that record that it'd be a problem for me to see, then the problem is that the provider is concealing information from me. If it'd be confusing, the provider should have already discussed it with me so I won't be confused. Omitting sensitive or irrelevant records from a copy sent to another party would be OK but the patient's copy should have complete information for every record the provider has for the patient, without exception or limitation.
Frankly as a patient I'd love a single standard format I could get and maintain myself, so when I went to a new doctor I could just hand them a USB drive or SD card with my complete record on it. It'd make it easier for me too, no more struggling to remember phone numbers of doctors I saw years ago and no more dealing with a doctor I saw ages ago having moved his office and my new doctor can't reach him to get the records.
Except that the reason so few get hit with the zero-day stuff is because of all the people running AV software that WILL detect it and report it so it can get added to the lists. If everybody were running MSE, the majority WOULD be getting hit with zero-day stuff because there wouldn't be any alerts for it until days or weeks after an infection started spreading. In infection-disease circles it's called "herd immunity": if a sufficiently large portion of the population is immune to a disease (through vaccination or natural immunity), those who aren't are protected simply by never coming in contact with any infected individuals. But as soon as the fraction of immune/protected individuals drops below that critical point, the protection rapidly disappears. And it's not a linear decline, it's almost an exponential drop-off in protection once you drop below the critical level. That's why, BTW, we're seeing outbreaks of diseases today that haven't been common since the 50s or earlier. Vaccinations virtually wiped them out mid-century, but now we've got generations who didn't get as consistently vaccinated because "That's all been wiped out, and anyway everyone's vaccinated so who's going to give it to my kid?". Herd immunity breaks down and hey presto, clusters of diseases that were supposed to have been wiped out start popping up.
Though, how often have we seen the statement "That's only a proof-of-concept, there's no need to worry about it because we haven't seen it in the wild." followed within weeks by announcements of that same malware appearing in the wild (and usually on a large scale)? I've long since filed "It's only a proof of concept." right alongside "What could possibly go wrong?" as a virtual guarantee that Murphy'll be visiting shortly.
Yep, but if they continue to call knowing that the debtor isn't there, they're in violation of various sections of the FDCPA. It's not usually hard to track the phone number back to a collections agency, they're not real good at hiding themselves. And once I know that, I respond to their question with "Is this $NAMEOFCOLLECTIONAGENCY?". That puts them in a bind and how they answer doesn't change the substance of my next statement, only it's phrasing: "The person XXXXX you are trying to contact does not live here and can't be contacted through this number. If you continue to call this number I will consider it harassment and a violation of the FDCPA.". Then I hang up. If I'm really annoyed and anticipating actually doing anything to them, I'd print out a quick little letter and spend a few bucks on registered mail, return receipt requested to their office. But if they really aren't calling for me or anyone here, usually just being firm gets them to stop, because they don't want the hassle and expense of sending someone to small-claims court and they really don't want the hassle of dealing with a default judgement if they don't. Judges may be unsympathetic to people trying to get free money via FDCPA/TCPA complaints, but it's easy to frame the complaint instead as an aggrieved uninvolved party who just wants the phone calls to stop who's faced with a company that just won't accept the truth.
If you're female, filing the harassing-calls paperwork might produce interesting results. Female getting calls at all hours, faked caller ID information, dead air (robodialer trying to find an agent to hand the call to) or a male who won't identify themselves (agent instructed not to give out information), you're getting creeped out by it (you probably are), that should get the incident routed over to Vice as a potential stalker.
That would be incorrect. See Section 806 of the FDCPA, 15 USC 1692d, which begins "A debt collector may not engage in any conduct the natural consequence of which is to harass, oppress, or abuse any person in connection with the collection of a debt.". There's also a kicker in section 805(b), which prohibits a debt collection from communicating with any third party without the consumer's consent except for the specific purposes described in section 804 on locating the actual consumer. So yes, the FDCPA provides remedies and protections for people other than the consumer.
Absolutely nothing. In fact, I think they've already found ways to break out of most of the hypervisors out there and gain access to the host machine from inside a VM. The only exceptions I can think of are the IBM mainframe hypervisors, and those have the dual advantages of a) decades of work finding and removing bugs and b) hardware that was designed to run the hypervisor and has special support for isolating the hypervisor from the virtual machines.
Bear in mind that for cloud applications you actually need to be worried about the reverse: protecting your application from the hypervisor breaking into it. The worst incursions won't be from other applications breaking out of their VMs, it'll be incursions from the cloud provider's own internal network (from conventionally-infected machines) infiltrating the host machines' hypervisor software and from there reaching down to infect hosted applications.
That's not specific to Java, it applies to all software that's downloaded from an outside source and run on your local machine. That means Adobe Reader (PDF is simply a wrapper for a program written in Postscript), Flash (ditto, written in a special programming language) and even Javascript. It even includes downloaded TrueType fonts (the font hinting program they can include is just that, an executable program). Don't dismiss them just because they're sandboxed. Java was sandboxed, that didn't stop this vulnerability. Sandboxes are software and software has bugs in it, always. The only question is the number and severity of the bugs. The simpler the software, the fewer bugs there tend to be because there's fewer places for them to hide. Their favorite hiding place is in unexpected interactions between different parts of a piece of software, or between the software and the system it runs in, and simpler software has fewer and simpler interactions that're easier to get right.
This even applies to software you buy from a vendor. The difference is that with bought software you tend to download it only a few times and always directly from the source. Contrast this with the Web, where you're downloading multiple pieces of software on virtually every Web page you hit with no idea where they're coming from (and, in the case of advertising networks, the place you download them from may not even know who or where they're coming from).
True, but then by going over to someone else I'm interrupting them just as much as people coming to me interrupts me. And much of the stuff can be handled better via e-mail, which leaves a nice neat paper trail of information that I can file and refer back to and is a lot less disruptive if properly used. Don't underestimate the value of that paper trail. A record of why you came to a particular decision about how to do things is more valuable than a simple description of the decision. Things will change over time, and you can't know if the reasoning behind a decision's still valid if you don't have a record of what that reasoning was. Having the conversation in e-mail automatically creates that record (assuming people file the e-mails, which I do). There's also IM and VoIP and desktop sharing, and it's amazing how effective those can be (especially when combined with webcams so you can see who you're talking to). I can reserve face-to-face for really critical issues.
As for group areas, I'd say that simply having several meeting rooms with network access should suffice. I've found it rare that I needed to be actually working in a group for any length of time, more often it's sit down as a group to bat issues around and come up with plans, then divide up and get working with individual conversations when needed. And one big bullpen area, suitable sound-isolated from the office area, where you can sit down for truly large meetings or for things like full deployment tests where for an afternoon you really are leaning over each other's shoulders to help sort out problems.
You want me to be productive as a developer? OK, here's what I need to do that:
A comfortable workspace. Give me a good solid desk with drawers and shelving to store reference and work materials. A phone with a headset so I can hold a conversation and work on the computer at the same time. A comfortable chair. Not one of the $99 specials from Office Depot, something high-end that's rated for 8 hours of continuous use. If what you're providing for an office workspace isn't at least as good as what I can afford personally at home, there's probably something wrong.
A good computer. It needs to have enough CPU horsepower and enough memory and disk for the software you expect me to be using. And it needs to be better than the minimum spec, I can't be productive when my tools are barely limping along. Good monitors too, and more than one. I'm going to regularly be pulling up digital reference materials and I'll have a lot of work on my screen, I need the screen real-estate to have all of it available without constantly having to shuffle windows to the top. You want to understand why, try doing your work with only one sheet of paper visible at a time and if you need to refer to 2 reports at once you have to lay one on top, read it, pull the other one out and lay it on top to read it, lather rinse repeat. If you don't think you can be productive working that way, why should you expect me to be?
Give me the reference materials and tools. If you expect me to work with tools or systems, give me all the documentation on them. It doesn't have to be physical, but it has to be available and up-to-date. If you want me to work on something, give me the tools to work on and with it. IDEs, editors, file comparison tools, merge utilities, it's possible to not skimp without going overboard. If you want me to work on software that accesses a database, give me a database client and access to those databases and a personal database I can play with to test things before I break the world for everybody else. If you want me to work on a system, set it up so I have my own installation I can put changes into to test. And for crying out loud, give me documentation on how to set it up and configure it and use it so I'm not completely lost going in.
Give me the ability to work uninterrupted. I know open-plan offices are all the rage, but you're expecting me to do work that requires high concentration for hours at a time. I can't do that with every conversation in the office distracting me, or everybody coming over randomly with questions or conversation. Same for phone calls. People should not be calling developers directly unless the developer's asked them to. If you need to, hire a receptionist to field calls and route them where they need to go (as opposed to where the caller wants them to go).
Let me work on my projects. I have a priority list. I use it to decide what things I should focus on now. But it doesn't do me any good if the priorities are constantly changing. I know, I know, the old saw about responding to business needs. Think a minute: maybe the problem isn't that I need to respond, but that business needs to start thinking more than a few days ahead? If requirements for a new project are constantly changing, perhaps you just don't have a good enough idea of what you want to start actual work on it yet. One of the worst ways to kill my productivity is to give me just enough time to get a handle on a project and start work, then make me drop it and start on a completely different project, and keep doing this repeatedly. When you pull me away from project A to work on B, it costs project A more than just the time I was working on B. The distraction will make me forget some of the details of what I was working on for A so when I get back to it I won't be able to just pick up where I left off, I'll have to backtrack and spend time remembering my train of thought and reconstructing all those details before I can start working again. So try to settle the priority lists down so they're not changing on a daily b
I always considered readability and maintainability to be implicit technical requirements for any project. Simply put, new people will have to read and understand the code, and you will have to maintain and enhance the code. The code therefore needs to be amenable to being read and maintained. If it isn't, you end up wasting time and resources fighting the code that could've been spent delivering new features.
Case in point: a data-acquisition component I work on. When I started it supported 3 data sources, and supported only straight-TCP network sources using source-specific protocols over a socket. It had a lot of problems, a lot of places where code for a common task had to be duplicated in the implementation of all 3 data sources and a lot of places where code was intertwined that didn't really have any commonality, but with such a small number of data sources it was livable-with. We rarely added data sources, so there wasn't a lot of payoff for improving the code.
But then after I started working on it, things changed. Instead of 1 new data source every 4-5 years, we got 3 new sources in one year. And a new type, based on HTTP POST rather than messages over a simple TCP socket. Worse, we were told that this kind of pace was going to continue, and that we were going to get more types of data sources like ones pulling from SOAP services (HTTP can still be thought of as text requests and responses, but SOAP ends up looking like actual objects and not simple text strings). It was taking too long to do simple things with the code, and we were spending too much time tracking down and fixing bugs caused by new changes breaking old code that we didn't realize was affected. So I pretty much twisted arms until I got the OK to rewrite it based on what I knew we were going to be asked to do.
The payoff? Cut the time to add a new type of data source in half. Cut the time to add a new data source of an existing type by 80%. Virtually eliminated a class of recurring bugs where we'd fixed the code in one data source but not in others because we missed multiple instances of common code. Cut the number of bugs where new changes broke existing data sources by 90+%. Took a class of request of the "This neat new feature for data source X? Can you add it to all the others?" sort and turned it from a days-long exercise in locating and modifying multiple copies of code to a quick exercise in passing the correct arguments to common functions.
The only way I'd accept the "only disclose to the owner" condition is if it included a time limit within which the owner must either fix the vulnerability or disclose the vulnerability to the public, and if the owner fails to meet the limit the confidentiality is lifted and the hacker is free to disclose the vulnerability himself. If software makers want their mistakes kept confidential then the cost is a binding commitment to fixing those mistakes, and the penalty for failing to meet their commitment is that the hackers are freed from theirs.
That's an odd position to take given the actual budget numbers. I collected some of them here. What's odd is that every Republican President since 1976 has presided over a larger year-to-year increase in both the debt and the deficit than the worst Democratic President (Carter). And you can't blame it on a Democratic Congress: the majority of of Clinton's term saw a Republican Congress, as did the majority of Bush Jr.'s terms, yet Clinton's terms saw net reductions in the deficit and rate of growth of the debt while Bush Jr. oversaw net increases in both. And Obama has had a Democratic Senate since he was elected and a Democrat-controlled House for half his term, yet again net reductions in the deficit and rate of growth of the debt. The numbers... appear to add up to exactly the opposite of your position.
Nope. All you need is a number of devices greater than the number required to cause a problem. We have evidence that it's greater than 2-3. Can you present any evidence that it's always going to be greater than the number of seats on the airliner in question?
Because with the flight crew you're dealing with a limited number of devices and a limited amount of potential RF interference. Extend that to passengers and you have not just 1-2 but possibly a hundred or more devices simultaneously, and that can have a drastically different effect on the avionics.
If I pour a gallon of water into a standard rowboat on a lake, it's not going to sink. If I pour another gallon of water in, it's still not going to sink. 2 gallons just isn't enough to cause a problem. even 5-6 gallons isn't. But if I pour a couple hundred gallons in, it's going to sink. I can't go "Well, adding another gallon didn't make a difference, so adding another gallon more won't either." indefinitely. At some point you reach the straw that broke the camel's back. When reaching that point can potentially get 200 or so people killed as the plane stops flying, I'd really rather we avoided going there.
Think about it a moment. The ultimate piece of malware would be one that can make your computer run software of someone else's choice, prevent you from running software other than the malware, and block you from removing the malware from the system or preventing it from running. Every piece of malware out there tries to do this, with varying degrees of success. Look at the malware that tries to disable anti-virus/anti-malware software.
Now, Restricted Boot would give someone else control over what software could boot on the machine, and prevent you from changing that list of authorized software. You cannot authorize software you want to run to run, nor can you remove authorization from software you do not want to run. You can't influence what runs at boot, you can't alter it's operation. In short, you've bought into every malware author's wet dream: a system where they can do anything they want and the user can't do a thing about it.
And if you think "Oh, but all the system software would be signed by Microsoft, so how would the malware authors get the keys to authorize their software?", think about this: Microsoft certificates have already been compromised. The bad guys have already gotten access to what they need to sign software with legitimate Microsoft keys. The certificates used by the Flame malware were only some of the most recent. And I'd note this older bulletin describing a situation where Verisign issued legitimate certificates issued to Microsoft to black-hats with no association with Microsoft. The bad guys obtaining the private keys to sign software isn't a theoretical discussion, it's already actually happened.
The right answer: "I screwed up. I accept responsibility for screwing up, and I'm going to take care not to screw up in the future (and especially not in the same way).".
This isn't backwards compatibility. It's the same basic rule we have to follow where I work: you DO NOT EVER make unannounced/unplanned changes that break the way other modules interact with yours. Period, end of line. Break that rule with any sort of regularity and you'll be looking for a job. If you need to make a change like that, it's on you to justify why and then to coordinate with everyone else to make sure everything that needs changed gets changed. It's not a hard rule to understand or to follow. If you can't, you have no business messing with an operating system kernel.
Which still leaves the unsafe condition of cars speeding through a construction zone. Unsafe not just for workers, but for the occupants of the cars if, for instance, there's a sudden lane position shift to avoid a solid obstacle, one that's safe at 25mph but unnavigable at 65mph. With a driver in the car, he can recognize that the car's failed to recognize and adapt to the situation, override the car and slow down to a safe speed.
That's also, BTW, why all those "silly" laws from the early days of cars aren't in fact silly. The guy walking ahead with the lantern or the limiting of the car's speed to that of a horse weren't for the car. They were for everybody else on the road who weren't used to cars (them being new and not commonly encountered), to give them warning and to keep them from having to face something coming at them unexpectedly and far faster than they were prepared to react to.
Sure, you can do it. Now, describe to me how you do it. Precisely. In detail. Clearly and simply enough that I can give a trained monkey your instructions and it can successfully do the same thing. Now, re-write those instructions so they still work when the monkey's trainer is reading over it's shoulder and going off and altering conditions with the express intention of making your instructions fail to work, because we all know Murphy's always out there just waiting for his chance and when you're talking 2 tons of steel moving at 65mph the failure modes tend to involve the emergency room and/or the morgue.
Yes, I'm being cynical and pessimistic here. I've spent too many years watching people answer my pointing out thread-unsafe constructs with "That's not a problem, it's a million to one we'll see that happen.". Yeah, and you're executing that stretch of code how many million times a minute? As I put it, "I'm one in a million? Gods, that means there's 310 more just like me in the United States ALONE, let's not even count the rest of the world...". Or, to a vendor, "Sorry, but 99.99% uptime means we can expect at least one of our stations to be down every day. That's unacceptable.".
Dirt, grime, frost, the idjit behind with the HID lamps on hi-beam making so much glare off the reflective surface of the sign that it's washing out the lettering, poor positioning so the sign's blocked from view until you're almost on it so the camera only gets a frame or two and then it's past the sign (seen that in construction zones, and the cops and the judges will cut you no slack for it), someone just plain forgot to put up the signs (also seen that, ditto on cutting you any slack)...
This, BTW, is why software has so many problems including so many security vulnerabilities: people go assuming the world's basically nice except for the occasional failure. But to make things reliable you have to assume the opposite, that the world's out to get you and is actively working to make things go wrong in the worst possible way at the worst possible time and you'll need to be prepared to handle it. In software development it's called "programming Satan's computer", and it's the only way to create highly-reliable software.