Not correct, at least not for the version of the GPL in question. Read the GPL v2 and look at section 3 which covers distribution. Your options:
3a: Distribute the source code along with the binaries. Using this option you only have to provide source to your customers.
3b: Distribute the source code separate from the binaries. This option explicitly requires you to make the offer of source available to any third party, regardless of whether they received binaries from you or not.
3c: Pass on the offer you received. This is only available for non-commercial distribution, so a company selling phones or software wouldn't qualify to use it.
You'd be correct for GPL v3, but the Linux kernel license lacks the "or any later version" language so v3's off the table as far as the kernel as a whole is concerned.
It depends on how they distribute the sources. If they accompany the binaries with the source code, then you're right. However, if they offer the sources for download or by any method not accompanying the binaries, they have to offer the source to any third party regardless of whether they're a customer or not. That's because the Linux kernel is under the GPL v2 with no option to use a later version, and section 3b of the GPL v2 specifically says the offer has to be good for any third party. 3a covers distribution only when the source accompanies the binaries, and 3c isn't available because it's only allowed for non-commercial distribution which this isn't.
"If someone breaks into my computer system, is it legal for me to break into his?". OK, rephrase it: "If someone breaks into my house, it is legal for me to break into his?". Answer the second, you've answered the first.
I've dealt with some of what's coming out of India. I hate to say it, but while individually their developers are sharp as tacks, collectively they lack a) experience and b) initiative. Given a clear set of instructions they can churn out the code, but it's often unpolished and missing those small critical bits that an experienced dev has learned you omit at your peril. Correct calls to base-class constructors for instance, and factoring of common bits of logic out into base-class methods that can be used without duplicating the code. 2 bits of logic will often be left intertwined, with no effort made at separating them if the original instructions didn't say to write them separately. That turns into a maintenance nightmare further down the road when we need to use just one part of the logic and we can't because it's tied up with another unrelated part that we don't want. And if you hand them a normal set of requirements where you haven't already done the analysis and design work, figured out how the code needs to be written and reduced it to a set of clear instructions for a coder? They'll still treat it as if you'd done all that and write exactly what you asked for, incomplete and ambiguous bits and all. This... does not add value at all. It adds profit margin for the shop in India doing the work, but it ends up costing more in the long run when maintenance involves re-writing the modules from scratch to make any significant changes.
The annoying thing is I know the individual developers on the India side are better than that. When I sit down and start talking with them, it's obvious they understand what I'm talking about. I can hear them recognize exactly what I'm talking about, and their immediate response starts right down the path to what I'd've done about the problems. But none of them have done long-term maintenance on software before. They haven't had to take the same code and do bugfixes and updates and enhancements on it for 5 years running. They're making the same mistakes I was making my first few major projects.
Come to think of it, those are the same mistakes I see contractors making a lot of the time. Which'd make sense, contractors follow the same pattern of coming in, doing specific bits of work and leaving, not having to stay with the same codebase over the long term. They never have to live with the consequences of the code they're writing or the work they're doing. And all too often, what's optimal in the short term is highly non-optimal over the long term. It reminds me somewhat of what my brother deals with at a gold mine. They've got some operators who run the mills with everything right at 100% capacity. That makes their single-shift production numbers look great, but there's no margin for error. Anything goes wrong anywhere in the system and everything overflows, and you end up with the mill floor 4' deep in mud and the whole mill shut down while it's cleaned up. And if the next shift after them slows things down to create some breathing space, that cuts their production down because they've got to run at 50% capacity for most of the shift. So while those operators might say they're doing good, just look at their production numbers, the mill superintendent's not impressed that total mill production goes up significantly when these guys go on vacation.
That's a point. I'd point out a few holes in the concept, though. Firstly is that the installer package lists dependencies for the installer, not the program itself. That poses a problem as the program auto-updates, since the dependencies for the installer package will be getting out of sync with the actual program dependencies (not everybody will update packages every time they run a game, in fact most won't). And it'll turn into an outright nightmare if the Valve devs aren't very very careful to play nicely with all other software in the system. Windows DLL Hell comes in large part from programs having overly-specific requirements for which versions of shared libraries they can use. The traditional Linux way of avoiding that is to not depend heavily on exact versions, which runs counter to the usual commercial-software practice of never allowing use of versions the software hasn't been tested with. What's the game software going to do when it's automatic update requires a dependency that isn't installed, or requires a newer version of a dependency than's currently installed? As user software it doesn't have any privilege to update packages.
I know ways to solve this, but they all start with a basic operation: completely re-write the game software to conform to Unix conventions. That means separating per-user configuration and data from the code, so you can package the code and install it at the system level and maintain updates only through the package management system while still keeping data per-user. But that completely precludes automatic updates.
If it does that, then why would it need packaged at all? Just provide the installer for download and let users run it. Since it's not installing anything at the system level, there's nothing that needs to be in the package management system. And since the installer won't need manual updating after you've got Steam itself installed (if it does need updated, presumably the auto-update function will handle that), there's nothing gained from having it under package management.
That would be correct if and only if the vendor is providing the source code along with the device. If they aren't, then GPL v2 section 3b applies:
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Emphasis mine. It doesn't say just customers. It doesn't say just people who have the binaries. It says "any third party". That means any third party, no further restrictions or conditions. The GPL v3 would let you limit your obligation to provide source to only those who have the binaries, but the Linux kernel is under GPL v2 without the clause allowing use of later versions.
And this is why you make sure of who's listed as the registrant. Not just the administrative contact, the registrant is the one who owns the domain. You can set the billing, technical and administrative contacts to whoever needs to run things day-to-day, but make sure the registrant contact information's set for the organization, not one single person within it. That way when someone goes rogue you don't need to involve ICANN, you can just contact the registrar as the registrant and get control back. It's still hassle, but much less hassle than a dispute proceeding.
It boils down (as it so often does) to management failure. Management failed to check up on how the system development was going. Management failed to schedule checks and test runs before the system went live (and probably failed to allocate enough people and budget to do the testing properly and resolve any problems even if they had scheduled time for testing). Management failed to look at what would actually be needed when laying down the requirements. And finally, management failed to make sure there was a backup plan in place for if things went south at release.
For instance, the failure to get information packets with required stuff in them into the hands of the volunteers. IT may be involved in creating the packets, but scheduling things so that those packets are created and distributed before the last minute is a management job. There's a few things that won't be final until the last minute, like voter lists, but things like poll-watcher certificates can be ready days or weeks ahead of time. Even the voter lists can be mostly prepared days ahead of time, with only final updates the night before. If you print and distribute the lists a couple days ahead, you also give yourself backup: if the final updates blow up or don't go out, your people still have lists that're probably 95% accurate which is better than having no lists at all. So why didn't the management running the Romney campaign have all those information packets printed up and distributed starting 3-4 days before Election Day? That would've given time for anyone who didn't get their packet to call in or go in and pick up a replacement. And why did management put something outside their control, the home printers of the volunteers, on the critical path for their plan? That's always asking for a disaster right there.
If this is how Romney and his friends run their businesses, it's no wonder those businesses are having problems. I've seen Cub Scout candy sales that're better organized and managed than this.
My thought: the Republicans say that they, with their business backgrounds, are so much better at running organizations that they ought to be given control of the country so they can run it right. Well, if this is an example of how organizations work when the GOP are running them, do we really want the entire country run this way?
That seems a little far-fetched. First, there's the delay. Most people aren't cold-blooded and thick-skinned enough to wait that long for their revenge, they'll go for it while the incident's fresh and they're good and mad. Second, above the doorframe? I can see thumb drives going undetected stashed in the sub-floor, but above a doorframe? You mean in 3 years nobody on the cleaning staff wiped off the top of the doorframe and knocked the drive loose? Nobody looked up on their way out and noticed it? 3 years is a bit long for that to be believable.
I don't have to be doing anything illegal to suffer harm. For instance, if I work for a GOP-supporting business my job may be at risk if they find out I support the Democrats. Note recent news stories of CEOs making fairly explicit threats to employees about what'd happen if they failed to support the GOP in the election (eg. http://www.jsonline.com/blogs/news/175797801.html). Just because something's legal doesn't mean I want the public at large, or even any specific third party, to know about it. Take your checking account register, for example, or the list of places you've shopped for gifts for your wife's birthday. Nothing illegal there at all, but you probably don't want your checking account activity posted on the Web or your wife finding out where you've been shopping before you hand her your gift.
It's called "putting them on notice". Sure, they'll still track me. But they can't claim that they didn't know I didn't want to be tracked, or that there was some implicit consent because I didn't tell them I didn't want to be tracked. It's like the fence with the "No Trespassing" sign on it: it won't stop someone from trespassing, but they can't claim they didn't know and thought it was OK. That doesn't matter unless I want to take official or legal action against them, but if I do it's a very useful thing to have available.
If I'm properly filtering at the border, I don't need to filter in the middle, in fact it shouldn't ever be even theoretically necessary and its none of the cores business what business deal I've signed at the border anyway.
That's the thing though: this problem happened in part because the networks that peer with PCCW trusted PCCW not to advertise any ASes that weren't supposed to be attached to their network. And you can't assume that these days.
I get the feeling that upstreams should start to not completely trust BGP announcements from peers. I know in my firewalls the configuration knows which networks ought to appear where, and the rules are set to block traffic when that network shouldn't be able to appear on that interface. Perhaps it's time to look into having an administrative communication of which ASes each peer ought to be handling, and having the BGP system at the upstream filter out or ignore announcements for ASes that that peer isn't supposed to be handling. The problem I see with that though is that it works well at the edges, but the closer to the core you get the larger the list of potentially valid ASes and I can see it getting unmanageable pretty quickly. But with the number of these incidents, I think we need to do something to change the assumption that you can unconditionally trust peers to only hand you valid routing data, because that assumption pretty clearly isn't true anymore.
Motorola did offer to license at a FRAND rate. This is normally followed by a negotiation (based on things like is the licensee offering a license to important patents in return), but Apple declined to negotiate. Note that "FRAND" does not mean "whatever rate the licensee wants to pay".
Yes, I'd rather have my taxes going towards this than many other things. But I think frankly we don't need another tax for it. It's traditionally been handled as quid-pro-quo: "Telco, we're giving you cheap access to the public right-of-way to run your wires. Part of your side of the bargain is you're going to maintain these important services. If you don't want to maintain them, then let's talk about what the market price is for access rights for all your wiring...".
This is a common problem: emergency and safety systems are completely pointless 99% of the time... until you have an emergency, at which point they're indispensable. It's like the bail-out bag in the closet with the first-aid kit and other necessities for an emergency: for years you wonder why you keep it because you never use it, until that day you didn't see coming when the fire department knocks on the door saying the fire's jumped the line and you've got 15 minutes before it gets here (which has happened here twice since I moved here, so not a theoretical example). Myself, I'd keep pay phones around as one of those necessary emergency expenses, the kind of thing you know you've needed in the past and will need in the future but that you won't have time to get deployed if you wait until you do need it.
Some of it, yes. The stuff I listen to a lot is all encoded 6-channel though. But even the plain stereo stuff goes through the normal audio processing. Bass goes to the subwoofer, mid-range and treble go to the front and rear pairs (so I get spatial fill, it's not just coming from in front of me). There's a major, major difference between what comes out of the 5.1 set vs. the plain no-subwoofer stereo speakers.
A really good set would have 2 channels per front/rear speaker, with treble split from the mid-range and each routed to a driver tuned for that frequency range. But for ordinary listening that's overkill, the treble response of the regular drivers is good enough.
Run the Resource Monitor and watch it, because the in-use numbers are misleading. On the 2GB machine I deal with at work, opening Visual Studio, the Oracle DB client and a couple of terminal and shell windows only shows me using less than 1.5GB of memory, but I'm actually using a lot more. I can tell because every time I do anything or switch windows the paging activity shoots through the roof. That means that that 1.5GB in-use is not sufficient for the workload and memory's being paged out and in to satisfy current demands. That's a bad thing because on a phone there isn't anywhere to page out to. Phones don't have hard drives (and the SD card is way too slow for paging space).
I'm not sure about integrated into the keyboard/monitor. I know my experience is that most keyboards (short of the type that cost $100+ for just the keyboard, no gaming features or LCDs, eg. Unicomp or WASD) have a working lifespan of less than a year. By that point either the keys are worn to the point they're illegible, or spills and gunk have gotten the keys gummed up to the point they won't work reliably. So I go to Fry's and buy another keyboard and plug it in and I'm good to go again. If the computer's integrated into the keyboard, replacing the keyboard means replacing the entire computer and then reinstalling everything from scratch. Not fun. I think the conventional desktop will remain a box for the chassis with separate keyboard, mouse, monitor etc. so we can replace the cheap subject-to-wear parts without having to replace the actual computer at the same time.
My phone won't become my computer because it's not about the CPU power. Hasn't been for ages now. The average phone already has more CPU power than the average desktop user makes use of. It's more about:
Memory. My computer has something like 16x as much RAM as my phone, which means it can run a lot more stuff simultaneously. It can run all those system-tray programs, without breaking a sweat. But RAM means power, and putting 8GB of RAM into a phone increases the power draw (modern memory requires not just constant power but constant refresh access) and decreases the battery life.
Size. My computer has 2 27" monitors on it, making for a lot more screen real-estate to work on. And I need it when I'm simultaneously writing a document, referring to a spreadsheet, several e-mail messages and a couple of Web sites, keeping track of a couple of IM conversations, and let's not forget Visual Studio with a dozen files open in it. You can't have that kind of screen space on a phone, you're physically limited by the size that can be conveniently held in one hand.
Peripherals. I mentioned monitors. There's also my good Model M keyboard (you don't appreciate a good keyboard unless you're working in a job where you're typing nearly constantly for hours on end), the high-end mouse, the small input tablet, the good 5.1 speaker set for the music, the scanner for getting paper documents into electronic form... You can't attach all that to a phone in any useful way.
Portability. Yes you can solve all the shortcomings of a phone with a dock and attached peripherals, but why? By the time you're done, you've removed the things you wanted from a phone: the ability to carry it in one hand, and to not have it tied down with wires. We're seeing with Win8 what the downsides are of trying to design a system for both phone/tablet and desktop uses, and you end up not being satisfactory for either so the idea of grabbing the phone out of the dock and going ends up hamstrung by that.
Price. One reason desktops are cheap is that they can use commodity parts and have enough open space in the case that they don't have to worry about power so much. Phones are almost 100% custom-built with a lot of work going in to designing parts that can be packed into that small a package with no ventilation at all in 100-degree ambient heat and not incinerate themselves. They're going to inevitably be more expensive than a desktop just because of that. And while Microsoft may be willing to hemorrhage money on hardware because it supports other revenue streams, phone manufacturers can't.
So while more cores may help phones do phone-like things better, especially combined with nifty ideas like Google Glass, but it's not going to help the phone replace my desktop.
If your writing code you can't read then it doesn't matter if your following a style or not. If you have a block of code that fails because you make a typo because of slop then you've proven you don't test your code, which again isn't a coding style issue.
Yes, testing will catch those errors. But as I said, it's about easy, not merely possible. Long experience has taught me that it's faster and less aggravating to catch errors like this before you get to the testing phase. Once in testing, every one of these errors increases the number of tests you have to run, slows down testing for the fundamental logic errors that code examination won't catch (the kind where the code's correct and does what you intended it to do, but what you intended isn't what the requirements call for) and generally causes more aggravation and frustration than you need at that stage. Especially when you're working to a deadline. Better to catch all of them in one scan and get them fixed before you start testing than to find them one at a time after you've started testing.
And unless it's a personal project you are not the only person who'll have to work on that code. The code has to not only be readable by you, it has to be readable by everyone who'll have to maintain that code after you. And that'll be a lot of people, production code has a ridiculously long lifespan (I'm dealing with code at work that's been there for 10-12 years and isn't going away any time soon). This is one of the reasons why I said that mostly the exact style isn't so critical (beyond avoiding those styles that make it easier to make mistakes and not spot them) as is having a consistent style throughout the code. It's easier to maintain code that's not a mish-mash of several different coding styles, and better if programmers adapt to the style of the existing code than ignore it and use whatever they want with no regard to whether it fits into it's surroundings.
Note that the above applies more generally than to just coding style. It's better and less likely to cause nasty bugs if you work within the existing architecture and design of a code-base than if you try to force something in that runs counter to that architecture. At work (again) I'm dealing with just that: a component has a basic design, a way of doing things, and business wants to do something that completely contradicts that basic design. Considering that that component's got better than a decade's worth of accumulated code, enhancements and special cases built up around that basic design, it makes what business wants akin to trying to reposition the structural members of just the first floor of the Sears Tower. And as usual most of what they want can be accomplished within the existing design, and another engineering change elsewhere will probably render the remainder moot.
If you make a typo in your code then you made a typo, the best code style in the world doesn't prevent mistakes.
Code style can, however, make it easier to spot typos when you make them, easier to scan for them. Eg. the regexp "if.* = " to spot use of an assignment inside an if condition, which is normally a bug. If you consistently use whitespace between tokens, it's easy to write that regexp and have it reliably catch all occurrences while also reliably not catching anything else. If you omit the whitespace, it's harder to come up with a check that's resistant to false positives (and a test that throws up a lot of non-matching lines isn't helpful, the errors get lost in the noise). It can be done, but this is about easy not merely possible. You can make pigs fly with a big enough rocket strapped to them, but if you want a flying animal it's easier to just start with a pigeon instead. And anyone who wants to use techniques that make it easier to make errors and harder to spot them when you do make them... is not a professional.
Poor or inconsistent coding style, OTOH, gets in the way of producing correct, working code. If you have to constantly stop to figure out how the current statement's nested or which block it's in, that takes time and attention away from concentrating on what the code's supposed to do. That means more errors, more bugs, more time debugging and a greater likelihood of missing bugs or a deadline or both. If I look at code and find no consistent coding style in it, that tells me that either the programmer didn't take too much care writing the code or there were several programmers working on it who didn't take any care to mesh their work. Either way it makes me wary of the code.
And while mostly the exact style doesn't matter, only that there's a consistent style, some styles do have their drawbacks. Forinstanceomissionofwhitespacetends tomakecertainerrorslike=vs==harder tostopandmorelikelytolinger. Now, how long did it take you to find the typo in the previous sentence? I rest my case.
Slashdot Mirror
Not correct, at least not for the version of the GPL in question. Read the GPL v2 and look at section 3 which covers distribution. Your options:
You'd be correct for GPL v3, but the Linux kernel license lacks the "or any later version" language so v3's off the table as far as the kernel as a whole is concerned.
It depends on how they distribute the sources. If they accompany the binaries with the source code, then you're right. However, if they offer the sources for download or by any method not accompanying the binaries, they have to offer the source to any third party regardless of whether they're a customer or not. That's because the Linux kernel is under the GPL v2 with no option to use a later version, and section 3b of the GPL v2 specifically says the offer has to be good for any third party. 3a covers distribution only when the source accompanies the binaries, and 3c isn't available because it's only allowed for non-commercial distribution which this isn't.
"If someone breaks into my computer system, is it legal for me to break into his?". OK, rephrase it: "If someone breaks into my house, it is legal for me to break into his?". Answer the second, you've answered the first.
I've dealt with some of what's coming out of India. I hate to say it, but while individually their developers are sharp as tacks, collectively they lack a) experience and b) initiative. Given a clear set of instructions they can churn out the code, but it's often unpolished and missing those small critical bits that an experienced dev has learned you omit at your peril. Correct calls to base-class constructors for instance, and factoring of common bits of logic out into base-class methods that can be used without duplicating the code. 2 bits of logic will often be left intertwined, with no effort made at separating them if the original instructions didn't say to write them separately. That turns into a maintenance nightmare further down the road when we need to use just one part of the logic and we can't because it's tied up with another unrelated part that we don't want. And if you hand them a normal set of requirements where you haven't already done the analysis and design work, figured out how the code needs to be written and reduced it to a set of clear instructions for a coder? They'll still treat it as if you'd done all that and write exactly what you asked for, incomplete and ambiguous bits and all. This... does not add value at all. It adds profit margin for the shop in India doing the work, but it ends up costing more in the long run when maintenance involves re-writing the modules from scratch to make any significant changes.
The annoying thing is I know the individual developers on the India side are better than that. When I sit down and start talking with them, it's obvious they understand what I'm talking about. I can hear them recognize exactly what I'm talking about, and their immediate response starts right down the path to what I'd've done about the problems. But none of them have done long-term maintenance on software before. They haven't had to take the same code and do bugfixes and updates and enhancements on it for 5 years running. They're making the same mistakes I was making my first few major projects.
Come to think of it, those are the same mistakes I see contractors making a lot of the time. Which'd make sense, contractors follow the same pattern of coming in, doing specific bits of work and leaving, not having to stay with the same codebase over the long term. They never have to live with the consequences of the code they're writing or the work they're doing. And all too often, what's optimal in the short term is highly non-optimal over the long term. It reminds me somewhat of what my brother deals with at a gold mine. They've got some operators who run the mills with everything right at 100% capacity. That makes their single-shift production numbers look great, but there's no margin for error. Anything goes wrong anywhere in the system and everything overflows, and you end up with the mill floor 4' deep in mud and the whole mill shut down while it's cleaned up. And if the next shift after them slows things down to create some breathing space, that cuts their production down because they've got to run at 50% capacity for most of the shift. So while those operators might say they're doing good, just look at their production numbers, the mill superintendent's not impressed that total mill production goes up significantly when these guys go on vacation.
That's a point. I'd point out a few holes in the concept, though. Firstly is that the installer package lists dependencies for the installer, not the program itself. That poses a problem as the program auto-updates, since the dependencies for the installer package will be getting out of sync with the actual program dependencies (not everybody will update packages every time they run a game, in fact most won't). And it'll turn into an outright nightmare if the Valve devs aren't very very careful to play nicely with all other software in the system. Windows DLL Hell comes in large part from programs having overly-specific requirements for which versions of shared libraries they can use. The traditional Linux way of avoiding that is to not depend heavily on exact versions, which runs counter to the usual commercial-software practice of never allowing use of versions the software hasn't been tested with. What's the game software going to do when it's automatic update requires a dependency that isn't installed, or requires a newer version of a dependency than's currently installed? As user software it doesn't have any privilege to update packages.
I know ways to solve this, but they all start with a basic operation: completely re-write the game software to conform to Unix conventions. That means separating per-user configuration and data from the code, so you can package the code and install it at the system level and maintain updates only through the package management system while still keeping data per-user. But that completely precludes automatic updates.
If it does that, then why would it need packaged at all? Just provide the installer for download and let users run it. Since it's not installing anything at the system level, there's nothing that needs to be in the package management system. And since the installer won't need manual updating after you've got Steam itself installed (if it does need updated, presumably the auto-update function will handle that), there's nothing gained from having it under package management.
K.I.S.S.: Learn this acronym and abide by it.
That would be correct if and only if the vendor is providing the source code along with the device. If they aren't, then GPL v2 section 3b applies:
Emphasis mine. It doesn't say just customers. It doesn't say just people who have the binaries. It says "any third party". That means any third party, no further restrictions or conditions. The GPL v3 would let you limit your obligation to provide source to only those who have the binaries, but the Linux kernel is under GPL v2 without the clause allowing use of later versions.
And this is why you make sure of who's listed as the registrant. Not just the administrative contact, the registrant is the one who owns the domain. You can set the billing, technical and administrative contacts to whoever needs to run things day-to-day, but make sure the registrant contact information's set for the organization, not one single person within it. That way when someone goes rogue you don't need to involve ICANN, you can just contact the registrar as the registrant and get control back. It's still hassle, but much less hassle than a dispute proceeding.
It boils down (as it so often does) to management failure. Management failed to check up on how the system development was going. Management failed to schedule checks and test runs before the system went live (and probably failed to allocate enough people and budget to do the testing properly and resolve any problems even if they had scheduled time for testing). Management failed to look at what would actually be needed when laying down the requirements. And finally, management failed to make sure there was a backup plan in place for if things went south at release.
For instance, the failure to get information packets with required stuff in them into the hands of the volunteers. IT may be involved in creating the packets, but scheduling things so that those packets are created and distributed before the last minute is a management job. There's a few things that won't be final until the last minute, like voter lists, but things like poll-watcher certificates can be ready days or weeks ahead of time. Even the voter lists can be mostly prepared days ahead of time, with only final updates the night before. If you print and distribute the lists a couple days ahead, you also give yourself backup: if the final updates blow up or don't go out, your people still have lists that're probably 95% accurate which is better than having no lists at all. So why didn't the management running the Romney campaign have all those information packets printed up and distributed starting 3-4 days before Election Day? That would've given time for anyone who didn't get their packet to call in or go in and pick up a replacement. And why did management put something outside their control, the home printers of the volunteers, on the critical path for their plan? That's always asking for a disaster right there.
If this is how Romney and his friends run their businesses, it's no wonder those businesses are having problems. I've seen Cub Scout candy sales that're better organized and managed than this.
My thought: the Republicans say that they, with their business backgrounds, are so much better at running organizations that they ought to be given control of the country so they can run it right. Well, if this is an example of how organizations work when the GOP are running them, do we really want the entire country run this way?
That seems a little far-fetched. First, there's the delay. Most people aren't cold-blooded and thick-skinned enough to wait that long for their revenge, they'll go for it while the incident's fresh and they're good and mad. Second, above the doorframe? I can see thumb drives going undetected stashed in the sub-floor, but above a doorframe? You mean in 3 years nobody on the cleaning staff wiped off the top of the doorframe and knocked the drive loose? Nobody looked up on their way out and noticed it? 3 years is a bit long for that to be believable.
I don't have to be doing anything illegal to suffer harm. For instance, if I work for a GOP-supporting business my job may be at risk if they find out I support the Democrats. Note recent news stories of CEOs making fairly explicit threats to employees about what'd happen if they failed to support the GOP in the election (eg. http://www.jsonline.com/blogs/news/175797801.html). Just because something's legal doesn't mean I want the public at large, or even any specific third party, to know about it. Take your checking account register, for example, or the list of places you've shopped for gifts for your wife's birthday. Nothing illegal there at all, but you probably don't want your checking account activity posted on the Web or your wife finding out where you've been shopping before you hand her your gift.
It's called "putting them on notice". Sure, they'll still track me. But they can't claim that they didn't know I didn't want to be tracked, or that there was some implicit consent because I didn't tell them I didn't want to be tracked. It's like the fence with the "No Trespassing" sign on it: it won't stop someone from trespassing, but they can't claim they didn't know and thought it was OK. That doesn't matter unless I want to take official or legal action against them, but if I do it's a very useful thing to have available.
That's the thing though: this problem happened in part because the networks that peer with PCCW trusted PCCW not to advertise any ASes that weren't supposed to be attached to their network. And you can't assume that these days.
I get the feeling that upstreams should start to not completely trust BGP announcements from peers. I know in my firewalls the configuration knows which networks ought to appear where, and the rules are set to block traffic when that network shouldn't be able to appear on that interface. Perhaps it's time to look into having an administrative communication of which ASes each peer ought to be handling, and having the BGP system at the upstream filter out or ignore announcements for ASes that that peer isn't supposed to be handling. The problem I see with that though is that it works well at the edges, but the closer to the core you get the larger the list of potentially valid ASes and I can see it getting unmanageable pretty quickly. But with the number of these incidents, I think we need to do something to change the assumption that you can unconditionally trust peers to only hand you valid routing data, because that assumption pretty clearly isn't true anymore.
Motorola did offer to license at a FRAND rate. This is normally followed by a negotiation (based on things like is the licensee offering a license to important patents in return), but Apple declined to negotiate. Note that "FRAND" does not mean "whatever rate the licensee wants to pay".
Yes, I'd rather have my taxes going towards this than many other things. But I think frankly we don't need another tax for it. It's traditionally been handled as quid-pro-quo: "Telco, we're giving you cheap access to the public right-of-way to run your wires. Part of your side of the bargain is you're going to maintain these important services. If you don't want to maintain them, then let's talk about what the market price is for access rights for all your wiring...".
This is a common problem: emergency and safety systems are completely pointless 99% of the time... until you have an emergency, at which point they're indispensable. It's like the bail-out bag in the closet with the first-aid kit and other necessities for an emergency: for years you wonder why you keep it because you never use it, until that day you didn't see coming when the fire department knocks on the door saying the fire's jumped the line and you've got 15 minutes before it gets here (which has happened here twice since I moved here, so not a theoretical example). Myself, I'd keep pay phones around as one of those necessary emergency expenses, the kind of thing you know you've needed in the past and will need in the future but that you won't have time to get deployed if you wait until you do need it.
Some of it, yes. The stuff I listen to a lot is all encoded 6-channel though. But even the plain stereo stuff goes through the normal audio processing. Bass goes to the subwoofer, mid-range and treble go to the front and rear pairs (so I get spatial fill, it's not just coming from in front of me). There's a major, major difference between what comes out of the 5.1 set vs. the plain no-subwoofer stereo speakers.
A really good set would have 2 channels per front/rear speaker, with treble split from the mid-range and each routed to a driver tuned for that frequency range. But for ordinary listening that's overkill, the treble response of the regular drivers is good enough.
Run the Resource Monitor and watch it, because the in-use numbers are misleading. On the 2GB machine I deal with at work, opening Visual Studio, the Oracle DB client and a couple of terminal and shell windows only shows me using less than 1.5GB of memory, but I'm actually using a lot more. I can tell because every time I do anything or switch windows the paging activity shoots through the roof. That means that that 1.5GB in-use is not sufficient for the workload and memory's being paged out and in to satisfy current demands. That's a bad thing because on a phone there isn't anywhere to page out to. Phones don't have hard drives (and the SD card is way too slow for paging space).
I'm not sure about integrated into the keyboard/monitor. I know my experience is that most keyboards (short of the type that cost $100+ for just the keyboard, no gaming features or LCDs, eg. Unicomp or WASD) have a working lifespan of less than a year. By that point either the keys are worn to the point they're illegible, or spills and gunk have gotten the keys gummed up to the point they won't work reliably. So I go to Fry's and buy another keyboard and plug it in and I'm good to go again. If the computer's integrated into the keyboard, replacing the keyboard means replacing the entire computer and then reinstalling everything from scratch. Not fun. I think the conventional desktop will remain a box for the chassis with separate keyboard, mouse, monitor etc. so we can replace the cheap subject-to-wear parts without having to replace the actual computer at the same time.
My phone won't become my computer because it's not about the CPU power. Hasn't been for ages now. The average phone already has more CPU power than the average desktop user makes use of. It's more about:
So while more cores may help phones do phone-like things better, especially combined with nifty ideas like Google Glass, but it's not going to help the phone replace my desktop.
Yes, testing will catch those errors. But as I said, it's about easy, not merely possible. Long experience has taught me that it's faster and less aggravating to catch errors like this before you get to the testing phase. Once in testing, every one of these errors increases the number of tests you have to run, slows down testing for the fundamental logic errors that code examination won't catch (the kind where the code's correct and does what you intended it to do, but what you intended isn't what the requirements call for) and generally causes more aggravation and frustration than you need at that stage. Especially when you're working to a deadline. Better to catch all of them in one scan and get them fixed before you start testing than to find them one at a time after you've started testing.
And unless it's a personal project you are not the only person who'll have to work on that code. The code has to not only be readable by you, it has to be readable by everyone who'll have to maintain that code after you. And that'll be a lot of people, production code has a ridiculously long lifespan (I'm dealing with code at work that's been there for 10-12 years and isn't going away any time soon). This is one of the reasons why I said that mostly the exact style isn't so critical (beyond avoiding those styles that make it easier to make mistakes and not spot them) as is having a consistent style throughout the code. It's easier to maintain code that's not a mish-mash of several different coding styles, and better if programmers adapt to the style of the existing code than ignore it and use whatever they want with no regard to whether it fits into it's surroundings.
Note that the above applies more generally than to just coding style. It's better and less likely to cause nasty bugs if you work within the existing architecture and design of a code-base than if you try to force something in that runs counter to that architecture. At work (again) I'm dealing with just that: a component has a basic design, a way of doing things, and business wants to do something that completely contradicts that basic design. Considering that that component's got better than a decade's worth of accumulated code, enhancements and special cases built up around that basic design, it makes what business wants akin to trying to reposition the structural members of just the first floor of the Sears Tower. And as usual most of what they want can be accomplished within the existing design, and another engineering change elsewhere will probably render the remainder moot.
Code style can, however, make it easier to spot typos when you make them, easier to scan for them. Eg. the regexp "if .* = " to spot use of an assignment inside an if condition, which is normally a bug. If you consistently use whitespace between tokens, it's easy to write that regexp and have it reliably catch all occurrences while also reliably not catching anything else. If you omit the whitespace, it's harder to come up with a check that's resistant to false positives (and a test that throws up a lot of non-matching lines isn't helpful, the errors get lost in the noise). It can be done, but this is about easy not merely possible. You can make pigs fly with a big enough rocket strapped to them, but if you want a flying animal it's easier to just start with a pigeon instead. And anyone who wants to use techniques that make it easier to make errors and harder to spot them when you do make them... is not a professional.
Poor or inconsistent coding style, OTOH, gets in the way of producing correct, working code. If you have to constantly stop to figure out how the current statement's nested or which block it's in, that takes time and attention away from concentrating on what the code's supposed to do. That means more errors, more bugs, more time debugging and a greater likelihood of missing bugs or a deadline or both. If I look at code and find no consistent coding style in it, that tells me that either the programmer didn't take too much care writing the code or there were several programmers working on it who didn't take any care to mesh their work. Either way it makes me wary of the code.
And while mostly the exact style doesn't matter, only that there's a consistent style, some styles do have their drawbacks. Forinstanceomissionofwhitespacetends tomakecertainerrorslike=vs==harder tostopandmorelikelytolinger. Now, how long did it take you to find the typo in the previous sentence? I rest my case.