I have a lot of information on 3.5" disks. Tax returns dating back to the 80's. Archives of papers that I wrote in school. Old programs that I wrote since I was like 7 years old. Sure, I could convert them all to a few CDs, but do I really want to spend all that time? I also have quite a few 5.25" disks (and one computer with a working drive). I've got Windows 2 on low density 5.25" (like 5 or 6 of them). I'm too lazy to convert them to CD/DVD, yet consider them too important to just "throw away". Sure, I'm not buying new drives, but I still do use them occasionally...
Some of us don't like our data being proxied and processed off our phones. I know it's a fine line, but my Android browser has good JS support. Why would I want to throw that away for a little bit of speed?
How can you have a pre-alpha release? I've always heard Alpha as a "feature preview", where it's not complete and there may be major bugs. Beta was when it was feature complete, but probably contains major bugs. And then Release candidates are for finding major and minor bugs, but should be production ready if none are found... Unless there's another definition I'm not aware of, how can you have pre-alpha code?
This. If they said it in the beginning, that's one thing. But telling us one thing, then later changing it and saying "well, all you need to do is tell us not to" is nothing more than a slimy practice. And I don't buy the "Well, we told you that we reserved the right to do it" argument. If they added controls to "opt-out" today, then they are acknowledging that there's more to it than what was written initially. What's the difference between that, and me going up to you on a busy street and saying "If you don't tell me no, your house is now mine" even if you didn't even hear it? Isn't that basically what they are doing here?
If the guy can't back up his claim he really shouldn't be speaking about it.
I agree 100%. My OP was pure speculation, and I noted it as such. Based on TFA, there was no details about how the attack took place, so we are only left to assume. And in my experience, most times when thousands of hosts on a single server are attacked (and no word of attack on other servers), it's typically the result of a flaw in that server. That's why I made my original statement. I have no proof other than my past experience investigating attacks for an open source project... At least I labeled my thoughts as conjecture...
It is? That's against everything I've heard/experienced. The Droid's has 24bit color vs the Nexus's 16bit. The Droid has Gorilla Glass vs regular glass for the Nexus. The Droid has a higher resolution (albeit slightly) at 854x480 vs the Nexus's 800x480. The only real area that I can find that the Nexus is better (in terms of display at least) is in contrast ratio (100,000:1 for the Nexus, and I couldn't find specs for the Droid, but I'm assuming it's significantly lower due to the TFT).
My point wasn't that the Droid kicks the Nexus's ass. My point was that the Nexus doesn't kick the Droid's ass. They are about even. Both have things that they do better than the other (and some MUCH better). But the claim that "The Droid pales in comparison" is pure BS...
Can you please enlighten me as to the great number of technical ways the Nexus is better? A better screen? Oh wait, no, that goes to the Droid. Better touch screen interface? Nope, the Nexus has be notorious with its issues... A GPU? Oh no, that's the Droid too. Better 3g connectivity? Oh wait, isn't the Nexus 1 having major 3G issues? Better WiFi? Oh wait, no, the Nexus 1 never actually got 802.11n... Battery Life? Kinda, the Nexus has 30 minutes more talk time, but the Droid has 20 hours more standby. Price? Oh no, that's right, you can find the Droid for $99... Oh I know, Android 2.1? Nope...
There are only 2 things that you can argue that the Nexus is better than the Droid at. CPU speed, and Network. In every other realm, they are at best tied and at worst the Droid edges out the winner...
That's the ticket here. The more manufacturers customize the OS, the slower and harder it will be to update to newer versions. It's a whole other layer that needs to be tested/redesigned. Right now, when the Droid gets updated, the only thing that really needs testing is the drivers. But with the Sense UI, the whole UI layer may break, so it requires significant developer time to adjust to the new OS. What this means for the end users is that instead of getting the latest upgrade 3 to 6 months after release, they'll be getting it 1 to 2 years after release (IF they decide to do it at all)... And people complain about fragmentation...
I wonder if infected sites should be held accountable for PC's that get infected.
I wonder if Godaddy should be held accountable for PC's that get infected. After all, it was on their servers, and they have the power to either pull the plug on the affected server(s) or to roll back backups (assuming they take backups). Considering this is a mass attack, does it imply that a weakness in their servers allowed the attack (As in one site was compromised, and the attacker gained access to the entire server through that one site)? If so, Godaddy is absolutely responsible. In fact, I would think they'd be liable to both the end users (people who got infected) and their customers for not adequately protecting them and affecting their reputation (Just take down the server already)...
Well, it depends. How many have their computers set to pull updates hourly? If you pulled the updates daily, and it was released an hour after you checked, you were fine (considering they pulled it the same day). So the only computers affected were those that polled in the several hour window that the update was available (Something like 8 hours IIRC). And that's not to mention those configurations that are set to pull updates weekly or more.
ZDNet notes a supermarket giant in Australia that had to close down its stores as they were affected by the bug, causing a loss of thousands of dollars.
A chain of supermarkets close down, and they only lose thousands
of dollars? Really? I would expect that figure to be a lot higher than that for a single store... Think about all the fresh produce that'll go bad (that have daily deliveries). Think of the power usage (lights, refrigerators). And that's assuming that they aren't paying any of their employees while the store is closed. I'd imagine the loss would be on the order of tens of thousands of dollars per store. Not thousands of dollars across all of the stores...
I was very intrigued by Open-AudIT. So much so, that I downloaded it. I looked at the source. And then I promptly deleted it. The few files I looked into could be used in a book for how NOT to program PHP. Too bad too. It looked like it had potential...
I've heard horror stories setting up Nagios, but to be honest, my setup was a breeze. I did the smart thing, and wrote templates for each kind of device I'd be using, and then setup Puppet to push new Linux servers into Nagios (and set them up properly) automatically. For my windows computers, AD automatically sets everything up for me (with the exception of adding the server to Nagios, which is done via a shell script). Granted, I have a small system now (only about 50 devices and 500 services), but I can provision new hosts/services in at most a few minutes as needed (Most of them are less than that, since it's automated). And for the record, Nagios does do SNMP. In fact, it's monitoring my phone system right now via nothing but autodetected SNMP. I'm not saying OpenNMS is bad at all. I'm just saying my experience with Nagios is nothing compared to what I've read others experience.
I use Nagios for that kind of thing. Don't get me wrong, it isn't "perfect" at it, but it does a decent job once setup. If you use parenting in the configuration files, you can click on "network map", and immediately see each hosts' dependencies. And IIRC there are comment fields that you can write misc information (such as rack position, switch position, model, make, etc)... And it's free...
Oh, fuck, are you wrong. Any truly-experienced professional would refuse to take such a job, just because the client is willing to accept PHP.
Just because you don't like the language doesn't mean it's bad... And just because you have a 9-5 job doesn't mean everyone is in a position to turn down paying (and well paying at that) gigs...
You advocate MySQL, so you probably aren't even aware of "advanced" concepts like foreign key constraints and transactions (yeah, they're still not supported by MySQL's default storage engine, MyISAM).
That's because MyISAM is designed for a different problem set. It was designed to be fast above all else. That's all. If you care about referential integrity, then use Postgres or InnoDB. If you want raw speed no RDBMS can match MyISAM for any kind of a reasonable cost... Remember, if the only tool that you have is a hammer, every problem looks like a nail. Personally, I do use MyISAM. And I use InnoDB. And I use MongoDB. I pick what I asses to be the best tool for the job. And like it or not, sometimes that's MyISAM. I've got about 400gb in various MyISAM databases, most with reasonable transaction rates (200+ reads per second) and I've never had a corrupt table or foreign key fall off. That's because I've designed my applications intelligently. Now, I'm not saying that foreign keys are stupid. I use them wherever I can. But realize that it's a tradeoff. What I can do with 1 MyISAM box it would take 3 or 4 InnoDB boxes to do (And likewise Postgres boxes, since it's no faster at reads). For some applications it's worth it. For others, it isn't. Responsible development would dictate choosing the appropriate tool for the job... To blindly dismiss a tool because you're biased against it would be irresponsible (and as such I'd never hire you)...
True, but business needs dictate software requirements. So that decision is out of my hands (but believe me, I'd LOVE to run an office full of Linux computers)...
Quite simple. Parents are afraid that they would actually need to parent their children. So instead, they turn to people like Jobs to try to restrict everything of what they consider moral questionability so that they don't need to...
Exactly... I love the "Think of the children" line that he uses. As if children should even be using smart phones if there exists content that they shouldn't see. Well played straw-man argument Jobs... Well played...
But I guess Apple want's to parent your kids for you too. New from Apple, the iDad! Never again will you need to know anything about your child's life, simply let the iDad do it for you!
Don't concede. They wouldn't need a new CPU if there was intelligence in the design. CPUs should not be talking directly to anything but memory. All other communication (other processors, PCIe, South Bridge, etc) should be done via a point to point protocol. So then the only thing tying a specific CPU to a specific mobo or socket would be the memory technology. The graphics communication could talk to a PCIe device for the display driving (for the actual conversion of signal to DVI). So a legacy mobo could simply use a dead simple PCIe device to do the translation. A newer one could build that device in. But electrically there should be no need for a new motherboard (since it's communicating out via the point to point protocol). The only thing that's really tying the CPU to a specific mobo/socket would be the memory technology (since the memory controller is on CPU, if a CPU has a DDR2 controller it can't be used in a DDR3 mobo and vise verse)... Intel does this because it can make more money on it. That's it... There's no other reason with today's technology to bind a particular CPU generation so tightly to a motherboard or socket...
You would need a new motherboard regardless if they changed the socket or not.
Ummm, why? You can upgrade the CPU on an AM2/AM2+ motherboard with at most a flash of the bios. And the AM2/+ CPUs are typically backwards compatible (a AM2+ will run on an AM2, but with reduced functionality). So that AM2 board you purchased 4 years ago is still compatible with the latest processors (but not with DDR3). Given AMD's track record with sockets, I'd be surprised if the AM3 gets "phased out" within the next 5 years (meaning that they stop releasing new processors for it)... So can you explain to me why Intel comes out with a new socket every year (seemingly at least)?
And you only need difference circuitry when the base implementation is flawed (Point to point protocols should be flexible for anything that you may want to be doing... Oh, and AMD has had integrated point to point for what, 9 years now? And Intel JUST introduced one maybe 6 months ago?)...
The iphone 2g, 3g, 3gs all weren't leaked like this a couple months in advance to create hype. They were immensely popular just because of Apple's fanbase. So with everyone anticipating the next iphone, why would Apple need to hype up the 4g like this?
Quite simple. They have good competition now. With phones like the Droid Incredible and the HTC Evo coming to market before (or have a good chance of making it before) the 4g, they want to give normal people a reason to wait...
Well, it's not as straight forward as it seems. If they switch from ARM to PowerPC or x86, it's still going to take a recompile. So then every person who's written code either will need to recompile for each platform, or it would need a fat binary (with binaries for each supported platform). When you have one or two platforms to support, a fat binary can seem like a good idea (and it may in fact be one). But if you're talking 4 or 5 platforms (with iterations of each), then is a fat binary really worth all that added weight (a 1mb program taking 5 or 6mb of space. A 20mb program taking 100+mb)??? If they are going the recompile route, then the app store would need to take into account the platform, and then serve the correct binary. It's definitely not hard, but it is an added level of complexity into an already complex system. What would happen when a developer only compiles for one platform? Does it not show for the rest? Or is Apple going to do all the compiling (you give them your source, and they generate and store the binaries)?
I'm not saying that this is a bad idea at all. I'm not saying it isn't interesting. I'm actually more curious about how they plan to implement it if this is what they are doing...
It would make sense... If it wasn't filled with nonsense. The larger die? It's because the system RAM is built into the chip. Not because it's running some new dual core design. Apple banned writing in another language. Not compiling using anything but XCode. Some of the converters out there will covert down to Objective-C and then compile them with XCode. With his speculation in the article, that should be fine (because it's compiling with their compiler, and should be the exact same as if written in O-C in the first place), but it's banned. I do agree that it is well written. But well reasoned? It starts with a pair of flawed premises, and then makes some pretty good reasoning based on them. But all of that reasoning is inherently flawed due to the flawed premise.
What bothers me, is that people who don't know any better will read this article and think "Woah, cool! They are doing something smart!" when it's all really unjustified based on his reasoning (I'm not going to comment on if it really is smart or not)...
Slashdot Mirror
I have a lot of information on 3.5" disks. Tax returns dating back to the 80's. Archives of papers that I wrote in school. Old programs that I wrote since I was like 7 years old. Sure, I could convert them all to a few CDs, but do I really want to spend all that time? I also have quite a few 5.25" disks (and one computer with a working drive). I've got Windows 2 on low density 5.25" (like 5 or 6 of them). I'm too lazy to convert them to CD/DVD, yet consider them too important to just "throw away". Sure, I'm not buying new drives, but I still do use them occasionally...
Some of us don't like our data being proxied and processed off our phones. I know it's a fine line, but my Android browser has good JS support. Why would I want to throw that away for a little bit of speed?
How can you have a pre-alpha release? I've always heard Alpha as a "feature preview", where it's not complete and there may be major bugs. Beta was when it was feature complete, but probably contains major bugs. And then Release candidates are for finding major and minor bugs, but should be production ready if none are found... Unless there's another definition I'm not aware of, how can you have pre-alpha code?
This. If they said it in the beginning, that's one thing. But telling us one thing, then later changing it and saying "well, all you need to do is tell us not to" is nothing more than a slimy practice. And I don't buy the "Well, we told you that we reserved the right to do it" argument. If they added controls to "opt-out" today, then they are acknowledging that there's more to it than what was written initially. What's the difference between that, and me going up to you on a busy street and saying "If you don't tell me no, your house is now mine" even if you didn't even hear it? Isn't that basically what they are doing here?
I agree 100%. My OP was pure speculation, and I noted it as such. Based on TFA, there was no details about how the attack took place, so we are only left to assume. And in my experience, most times when thousands of hosts on a single server are attacked (and no word of attack on other servers), it's typically the result of a flaw in that server. That's why I made my original statement. I have no proof other than my past experience investigating attacks for an open source project... At least I labeled my thoughts as conjecture...
It is? That's against everything I've heard/experienced. The Droid's has 24bit color vs the Nexus's 16bit. The Droid has Gorilla Glass vs regular glass for the Nexus. The Droid has a higher resolution (albeit slightly) at 854x480 vs the Nexus's 800x480. The only real area that I can find that the Nexus is better (in terms of display at least) is in contrast ratio (100,000:1 for the Nexus, and I couldn't find specs for the Droid, but I'm assuming it's significantly lower due to the TFT).
My point wasn't that the Droid kicks the Nexus's ass. My point was that the Nexus doesn't kick the Droid's ass. They are about even. Both have things that they do better than the other (and some MUCH better). But the claim that "The Droid pales in comparison" is pure BS...
Can you please enlighten me as to the great number of technical ways the Nexus is better? A better screen? Oh wait, no, that goes to the Droid. Better touch screen interface? Nope, the Nexus has be notorious with its issues... A GPU? Oh no, that's the Droid too. Better 3g connectivity? Oh wait, isn't the Nexus 1 having major 3G issues? Better WiFi? Oh wait, no, the Nexus 1 never actually got 802.11n... Battery Life? Kinda, the Nexus has 30 minutes more talk time, but the Droid has 20 hours more standby. Price? Oh no, that's right, you can find the Droid for $99... Oh I know, Android 2.1? Nope...
There are only 2 things that you can argue that the Nexus is better than the Droid at. CPU speed, and Network. In every other realm, they are at best tied and at worst the Droid edges out the winner...
That's the ticket here. The more manufacturers customize the OS, the slower and harder it will be to update to newer versions. It's a whole other layer that needs to be tested/redesigned. Right now, when the Droid gets updated, the only thing that really needs testing is the drivers. But with the Sense UI, the whole UI layer may break, so it requires significant developer time to adjust to the new OS. What this means for the end users is that instead of getting the latest upgrade 3 to 6 months after release, they'll be getting it 1 to 2 years after release (IF they decide to do it at all)... And people complain about fragmentation...
I wonder if Godaddy should be held accountable for PC's that get infected. After all, it was on their servers, and they have the power to either pull the plug on the affected server(s) or to roll back backups (assuming they take backups). Considering this is a mass attack, does it imply that a weakness in their servers allowed the attack (As in one site was compromised, and the attacker gained access to the entire server through that one site)? If so, Godaddy is absolutely responsible. In fact, I would think they'd be liable to both the end users (people who got infected) and their customers for not adequately protecting them and affecting their reputation (Just take down the server already)...
Well, it depends. How many have their computers set to pull updates hourly? If you pulled the updates daily, and it was released an hour after you checked, you were fine (considering they pulled it the same day). So the only computers affected were those that polled in the several hour window that the update was available (Something like 8 hours IIRC). And that's not to mention those configurations that are set to pull updates weekly or more.
A chain of supermarkets close down, and they only lose thousands
of dollars? Really? I would expect that figure to be a lot higher than that for a single store... Think about all the fresh produce that'll go bad (that have daily deliveries). Think of the power usage (lights, refrigerators). And that's assuming that they aren't paying any of their employees while the store is closed. I'd imagine the loss would be on the order of tens of thousands of dollars per store. Not thousands of dollars across all of the stores...
I was very intrigued by Open-AudIT. So much so, that I downloaded it. I looked at the source. And then I promptly deleted it. The few files I looked into could be used in a book for how NOT to program PHP. Too bad too. It looked like it had potential...
Wow, does that ever read like a sales pitch...
I've heard horror stories setting up Nagios, but to be honest, my setup was a breeze. I did the smart thing, and wrote templates for each kind of device I'd be using, and then setup Puppet to push new Linux servers into Nagios (and set them up properly) automatically. For my windows computers, AD automatically sets everything up for me (with the exception of adding the server to Nagios, which is done via a shell script). Granted, I have a small system now (only about 50 devices and 500 services), but I can provision new hosts/services in at most a few minutes as needed (Most of them are less than that, since it's automated). And for the record, Nagios does do SNMP. In fact, it's monitoring my phone system right now via nothing but autodetected SNMP. I'm not saying OpenNMS is bad at all. I'm just saying my experience with Nagios is nothing compared to what I've read others experience.
I use Nagios for that kind of thing. Don't get me wrong, it isn't "perfect" at it, but it does a decent job once setup. If you use parenting in the configuration files, you can click on "network map", and immediately see each hosts' dependencies. And IIRC there are comment fields that you can write misc information (such as rack position, switch position, model, make, etc)... And it's free...
I love that TFA states that they hired a cartographer to make the map... A programmer, sure. But a cartographer? Really?
Just because you don't like the language doesn't mean it's bad... And just because you have a 9-5 job doesn't mean everyone is in a position to turn down paying (and well paying at that) gigs...
That's because MyISAM is designed for a different problem set. It was designed to be fast above all else. That's all. If you care about referential integrity, then use Postgres or InnoDB. If you want raw speed no RDBMS can match MyISAM for any kind of a reasonable cost... Remember, if the only tool that you have is a hammer, every problem looks like a nail. Personally, I do use MyISAM. And I use InnoDB. And I use MongoDB. I pick what I asses to be the best tool for the job. And like it or not, sometimes that's MyISAM. I've got about 400gb in various MyISAM databases, most with reasonable transaction rates (200+ reads per second) and I've never had a corrupt table or foreign key fall off. That's because I've designed my applications intelligently. Now, I'm not saying that foreign keys are stupid. I use them wherever I can. But realize that it's a tradeoff. What I can do with 1 MyISAM box it would take 3 or 4 InnoDB boxes to do (And likewise Postgres boxes, since it's no faster at reads). For some applications it's worth it. For others, it isn't. Responsible development would dictate choosing the appropriate tool for the job... To blindly dismiss a tool because you're biased against it would be irresponsible (and as such I'd never hire you)...
True, but business needs dictate software requirements. So that decision is out of my hands (but believe me, I'd LOVE to run an office full of Linux computers)...
Unless as a sysadmin you chose another product other than McAfee (I personally use Symantec)...
Quite simple. Parents are afraid that they would actually need to parent their children. So instead, they turn to people like Jobs to try to restrict everything of what they consider moral questionability so that they don't need to...
Exactly... I love the "Think of the children" line that he uses. As if children should even be using smart phones if there exists content that they shouldn't see. Well played straw-man argument Jobs... Well played...
But I guess Apple want's to parent your kids for you too. New from Apple, the iDad! Never again will you need to know anything about your child's life, simply let the iDad do it for you!
Don't concede. They wouldn't need a new CPU if there was intelligence in the design. CPUs should not be talking directly to anything but memory. All other communication (other processors, PCIe, South Bridge, etc) should be done via a point to point protocol. So then the only thing tying a specific CPU to a specific mobo or socket would be the memory technology. The graphics communication could talk to a PCIe device for the display driving (for the actual conversion of signal to DVI). So a legacy mobo could simply use a dead simple PCIe device to do the translation. A newer one could build that device in. But electrically there should be no need for a new motherboard (since it's communicating out via the point to point protocol). The only thing that's really tying the CPU to a specific mobo/socket would be the memory technology (since the memory controller is on CPU, if a CPU has a DDR2 controller it can't be used in a DDR3 mobo and vise verse)... Intel does this because it can make more money on it. That's it... There's no other reason with today's technology to bind a particular CPU generation so tightly to a motherboard or socket...
Ummm, why? You can upgrade the CPU on an AM2/AM2+ motherboard with at most a flash of the bios. And the AM2/+ CPUs are typically backwards compatible (a AM2+ will run on an AM2, but with reduced functionality). So that AM2 board you purchased 4 years ago is still compatible with the latest processors (but not with DDR3). Given AMD's track record with sockets, I'd be surprised if the AM3 gets "phased out" within the next 5 years (meaning that they stop releasing new processors for it)... So can you explain to me why Intel comes out with a new socket every year (seemingly at least)?
And you only need difference circuitry when the base implementation is flawed (Point to point protocols should be flexible for anything that you may want to be doing... Oh, and AMD has had integrated point to point for what, 9 years now? And Intel JUST introduced one maybe 6 months ago?)...
Quite simple. They have good competition now. With phones like the Droid Incredible and the HTC Evo coming to market before (or have a good chance of making it before) the 4g, they want to give normal people a reason to wait...
Well, it's not as straight forward as it seems. If they switch from ARM to PowerPC or x86, it's still going to take a recompile. So then every person who's written code either will need to recompile for each platform, or it would need a fat binary (with binaries for each supported platform). When you have one or two platforms to support, a fat binary can seem like a good idea (and it may in fact be one). But if you're talking 4 or 5 platforms (with iterations of each), then is a fat binary really worth all that added weight (a 1mb program taking 5 or 6mb of space. A 20mb program taking 100+mb)??? If they are going the recompile route, then the app store would need to take into account the platform, and then serve the correct binary. It's definitely not hard, but it is an added level of complexity into an already complex system. What would happen when a developer only compiles for one platform? Does it not show for the rest? Or is Apple going to do all the compiling (you give them your source, and they generate and store the binaries)?
I'm not saying that this is a bad idea at all. I'm not saying it isn't interesting. I'm actually more curious about how they plan to implement it if this is what they are doing...
It would make sense... If it wasn't filled with nonsense. The larger die? It's because the system RAM is built into the chip. Not because it's running some new dual core design. Apple banned writing in another language. Not compiling using anything but XCode. Some of the converters out there will covert down to Objective-C and then compile them with XCode. With his speculation in the article, that should be fine (because it's compiling with their compiler, and should be the exact same as if written in O-C in the first place), but it's banned. I do agree that it is well written. But well reasoned? It starts with a pair of flawed premises, and then makes some pretty good reasoning based on them. But all of that reasoning is inherently flawed due to the flawed premise.
What bothers me, is that people who don't know any better will read this article and think "Woah, cool! They are doing something smart!" when it's all really unjustified based on his reasoning (I'm not going to comment on if it really is smart or not)...