But what happened to using the best tool for the job? There is a lot of impressive technology in.NET, but is it really the best tool for every job, now and in the future? In my view, it isn't, and can't be.
There are many cases where using the "right tool" offers dramatic performance improvements over the wrong tool. For example, writing large scale structured data storage in C is probably a bad idea, but SQL does the job just wonderfully.
But most cases aren't so clear cut.
At my company, we're a Unix/LAMP shop focusing on PHP and Postgres. Gguess what our server administration scripts run? There's a small amount of BASH, but by and large, it's all.... PHP!
Not that PHP is the ideal language for system administration and coordinating backups or system updates, but it's "good enough" and we're already familiar with it. By having it all written in PHP we get "plenty good enough" performance and the knowledge that any of our developers can pick up the script and immediately start reading it without having to think about the nuances of a different language.
And really, even if there's a 10:1 system performance difference, does it make any difference if the background task completes in 5 seconds instead of 0.5 when it reduces overhead elsewhere?
The "best" tool for the job is often the most conveniently available tool for the job...
There's been a raging debate internally as to whether or not we should change to hashed passwords. (for historical reasons, passwords aren't hashed now)
I've pushed for hashing repeatedly, but it's always been downsided by the fact that users are often technological cave-dwellers who have trouble turning their computer ON, let alone not being able to get their password from a support staff.
However, I'm not sure it matters so much, anyway. There are a number of techniques (such as hash tables) that make hashing much less usable, this GPU attack only exacerbates an already bad situation.
I'm of the opinion that anything less than 2 factor authentication is broken now or soon, anyway. I'm in favor of a random, cell phone text tied to the password, myself, except that texts are sometimes delayed. It works like a one-time password and can't meaningfully be broken since the time window of opportunity is far less than the password timeout for trying again.
Done right, this can't even be used to cause a DDOS because, if it's tied to IP addresses, the cracker would have to work 24x7 for a few hundred thousand years to make the window of opportunity, or, use a few hundred thousand IP addresses for a year to do the same in a year.
Since my software company is still mostly regional in nature, it's rare for me to fly more than a 1-2 hour hop at a time. It's barely worth pulling my laptop out at all since I have to wait until about 15-30 minutes until after boarding to begin, and have to put things away 15-30 minutes before actually getting off the plane.
If there was some way that I could sit down, plug in and sign on, and use my computer while the plane is preflighted, taxi, waiting at the taxiway, takeoff, and then final descent from 10,000 to landed and departing the plane, I'd be far, far more likely to pay for the short-ish hops that I tend towards.
And don't give me the "radio interference" crap - there's no evidence at all to support this and it's routinely ignored by anybody in the industry. Think about it: how many routine flyers, do you think, have forgotten to turn off their phone when they sit down, or just didn't bother? How many incidents have occurred as a result?
It's zero, in case you are wondering....
On another note, I routinely send texts while flying my private plane, which I also use for the shorter end of the hops I take. (whichever's cheaper and/or more convenient)
Prepared statements are a decent half-step, but they aren't easily applicable to variable-length queries such as "advanced search" or anything else with optional parameters. It's far too easy to hit one of these walls and fall back into sloppy coding to get around it, negating what little advantage the prepared statements offered.
I don't like prepared statements for the very same reasons. For this reason, we've built our own prepared-statements-like tool that gives us the same advantages of a prepared statement without requiring us to register the statement first.
A preprocessor takes two inputs: the query with string variables embedded, and an array of inputs to match the string variables. In PHP:
$sql="select lastname from users where login = '@login'"; $vars = array('login' => $_REQUEST['login']); $exec = PrepareQuery($sql, $vars);
The PrepareQuery() function looks for the variables in the sql and replaces them with values passed in, properly sanitized. (DB_escape_string(), etc) The result is very robust and also allows for very dynamic use such as dynamically created queries with optional values, etc.
I've yet to run into a scenario that this model didn't easily handle.
As the CTO of our small company, it bothers me that we use Skype internally. It is very convenient and productive to be able to have snap meetings and group discussions mid-day without having to go through the pain of calling everybody, etc.
But what bothers me is that all this information is going through a 3rd party's servers and I'm pretty paranoid. Ideally, I'd want a service that was cross platform, convenient, and provided a nice mix of calling, video sharing, and text chats across all platforms. Skype does an awful good job at this at the cost of privacy/security issues.
Now my small company does nothing that would be a tremendous surprise if revealed, but it does bother me to give this kind of information to *any* third party.
And when I say "all platforms", that's what I mean: Windows, Mac, Linux, Android, iPhone, Blackberry, etc. which we get now with Skype.
Recently, after reading performance reviews on the Vertex 3, I bought one. The speed is simply amazing! I've been using it as a data-intensive development database server drive. Shortly after buying it, I discovered that there were numerous complaints about the Vertex 2 being unreliable.
To this, I can only say that after about 6 weeks of extremely heavy use as the data partition on a PostgreSQL 8.4 server I've had no issues so far.
Why...why...WHY do people still insist on plain text passwords? Have these people ever heard of a hash? There is 0 reason ever to store a plaintext password, end of story. Anyone who designs a system that stores passwords in plain text should be fired on the spot.
I agree that saving passwords as hashes presents a much better security model, but you are just wrong to think that there is no reason to keep them in plain text.
The real world isn't quite so black and white!
1) It's "unfriendly" to require users to change their password every time. If the user is able to authenticate themselves sufficiently by other means, it may be perfectly legit to give them their password. Sorry, but real users often have a tough time figuring out how to turn on the computer, let alone remember a 12-digit password made of random letters, numbers, symbols and mixed case.
2) Done right, passwords can be invalidated at any time, forcing end users to re-specify a new password. Sufficient logging can also make it pretty clear if you have a security breach on your hands by noting other details of the login process. (EG: Source IP, etc)
3) Many (most?) breaches nowadays don't consist of somebody knowing the passwords, but in the "lost password" process which presents its own security issues - for example, email is sent in plaintext. Against this type of attack, hashes provide no security benefit whatsoever.
4) Debugging: It's nice when, as a developer, you are given access to real, honest-to-god data so that you can code to what's really happening rather than contrived, artificial data sets. Part of working in this type of environment is to be able to access dev copies of databases as users in question. Yes, you can set the passwords as part of the snapshot/replication process, but that does add overhead.
I guess what I'm saying is that storing hashes is like requiring super-strong passwords so that users end up with their password on a sticky note next to the computer: yes you get theoretically better security but it doesn't always work out that way in practice.
Like many decisions, you really have to evaluate this on a case-by-case basis, and you may offset some of the risk by doing things like enforcing the use of SQL prepared statements, or standardizing your data input validation!
And, in all truth, passwords are a terrible, terrible security tool, they just happen to have a better mix of usability, security, and convenience than anything else that's been developed thus far.
I agree that carbon indulgences are bullshit. If you actually give a shit, then consume less. If you don't actually give a shit, then man up and say so, like Mark Cuban did.
I really don't get this point of view, at all, and I say this as a rides-his-bike-to-work-everyday green hippie programmer type who also happens to own a private aircraft. The problem with burning oil is that it releases CO2 into the atmosphere, and your post confirms this.
So why is sequestering CO2 in one place to offset CO2 usage in another, more advantageous place, a bad idea? (shrug)
Listen, we're a LAMP shop, RHEL and/or CENTOS all the way! We've been in business for a decade, and currently have a 20-node cluster for our $2 million/year niche software company, averaging about 20%/year growth, even with the down economy.
And although we're a LAMP shop, I can tell you that hardware/licenses are a tiny part of the costs of our business if the application is structured correctly. ONE of our clients had a dozen servers before switching to our system. Our cluster of (at the time) 6 nodes didn't even register the increase in traffic meaningfully.
It wouldn't have been much different had we gone with Windows Server vs Linux, both can be viable. Licensing costs are a small fraction of the total! There's administration overhead. Power. Bandwidth. Backups. and on, and on. Administration costs dwarf your licensing costs!
Don't avoid Windows to avoid licensing costs, go with Linux because of the fairly significant reduction in Administration costs! Even with 20 nodes and hundreds of clients, thousands of users, we still have only a very part-time admin. (me)
Finite wireless spectrum?!? What are you talking about? Let's talk Mhz:
There is Ghz spectrum between say, 2.4 and 3.4 Ghz, which seems limited. So you might break it out into 1 mhz bands, giving you 1,000 usable frequencies. Or break it more finely,into.1 mhz bands giving you 10,000 usable, or.01 giving you 100,000 frequencies, or...
Take a look at the numbers, to goes on for a LONG time, limited only by our ability to generate better, more accurate crystals to filter out unwanted frequencies.
But wait! There's more! In practical use, most allocated frequencies aren't used most of the time. The vast majority of the regulated spectrum is... dark! It's ALLOCATED but isn't USED much at any specific time, meaning that most of the 'limited' bandwidth is an artifact of a regulatory system constructed during an era when people tuned their radios by jiggering a wire on the surface of a crystal.
Spread spectrum technology, first developed by military for secretive radio communications, send information in short bursts in pseudorandom frequencies. This frquency hopping allows for far more efficient use of existing radio frquencies with minimal disruption. Numerous studies show this type of technology could extend the available bandwidth a billionfold or more.
Sorry, the only limits to wireless bandwidth are our own limits of ingenuity.
You can't technically fix stupid; users that install everything they see will always be the weakest point in system security.
I'd argue that this is NOT the case, just that it's difficult. It's true that given a gun, basically anybody can shoot themselves in the foot. But the basic problem is that there's no easy way to differentiate between a "legit" program that will do you a favor, and one that will do malicious stuff.
The App Store concept solves this problem pretty handily. I'm leery of installing *anything* not found in the App Store simply because I don't want to have to worry about whether or not it will brick my phone or whether I can uninstall it.
Of course, the App Store concept has its own problems, but the Linux Repo model solves this nicely. Repos can be (usually are!) totally open, and for the most part, I just don't install anything I don't find in a few trusted repos. I get all the software I want, I don't have to worry about getting a virus/worm/malware, and getting updates is as easy as ever.
I develop HTML5 based robotic heart surgery machines running on top of jQuery beneath AJAX served by node.js off of an Amazon mounted Rackspace Cloud written in Clojure, and I've had it with LCD Screens, CRTs, and so-called editors.
A classic case of using the WRONG TOOL for the job. (I know you were trying to be funny, but still...)
Well that is the answer to his question. Windows is actually quite stable now, on par with Linux.
Well, believe what you wish, I suppose. Over this last weekend, I set up my wife's laptop with Windows 7/64. The number of reboots I had to go through after the O/S install in order to get everything updated was no less than 10 or so, over a few hours. Mind you, this wasn't when setting up drivers, this was *after* I'd loaded the O/S and the drivers. This was just to apply security updates.
I have quite a number of Linux/RedHat/CentOS servers that I maintain, and when I build a new server, I have to reboot exactly one time after loading the O/S to apply updates. Literally, I type a single line as:
yum -y update && shutdown -r now;
That's it. That's the entire sum of the update process, after which I have a fully working, fully updated server with all updates updated.
Limewire has announced a strategic partnership with L1mew1re, wherein any assetts of value of Limewire will be transferred to L1mew1re, which will maintain said assets and lease their use to Limewire.
Limewire's company attorney, while available for comment, was unable to complete a sentence without screaming "bankruptcy, you bastards!!" randomly, mid sentence.
But with the least of four evils (T-Mobile USA) soon to be bought by arguably the greatest of them (AT&T), what do you recommend that smartphone customers who value their freedom do?
What? Four evils? There are other (uhmm) evils out there!
If price is your gig, consider MetroPCS, which happily supports Android phones for just $45/month. Data network is pretty slow, so don't use it for loads of youtube, it's not going to happen. But it's great for email, messaging, iTune remote radio, and navigation.
Metro not available in your area? Well, consider Cricket Wireless. Sporting somewhat better coverage than Metro PCS and somewhat higher prices, they too happily support Android, showing a popular LG Optimus on the home page. (The same phone my wife has; she loves it!)
I switched my family, kids and all, to MetroPCS. My monthly phone costs have dropped by more than half, and I'm not inundated with "phantom charges" which were sprouting like malignant cancers on my monthly cell bills with Verizon Wireless.
Giving dollars to the smaller carriers is a vote for consumer choice, a decision I made recently and I regret it for not a minute.
Unless, it really IS a growing company, at which point you stay as close as humanly possible - there is almost no place as secure as a position in a rapidly growing company, and, as much as I hate to say it, growth costs money!
For example, let's say you have a business where you have terms of "net 30", meaning you submit the bill, and the customer pays within 30 days. Implied is the idea that you deliver service for 30 days before billing. And it takes 30 days for most companies to run the bills for the previous month and figure out what happened and how much was made.
Each of these steps are vulnerable to the "+1" problem, so that it takes 2 months to finish instead of 1. Which means that, for a minimum period of between 90 and 180 days. Up to 180 days (about 6 months) of costs going out the door for an increase in service level unmatched by income.
That, my friends, is where the term "cash poor" comes from, and this kind of "cash poor" is almost exactly where you want to be when jobs are tight.
Don't assume anything without a reason for the assumption.
Trains can carry an entire ton of cargo 500 miles while expending a single gallon of diesel fuel. Because of the extremely steady load, train engines routinely pull a million miles or more (with an overhaul every few hundred thou) before needing replacement.
Further, train tracks cost much less to maintain per mile than roads.
Now, I do realize that I'm referring partially to cargo rail common in the USA, rather than the higher speed passenger trains, but even so, the costs per passenger mile for any train should be dramatically less than car, bus, or plane.
Sounds like corruption at work, if you ask me. (Same as the USA loan crisis)
Both IOS and Android were written by programmers, who tend to LOG EVERYTHING.
I provide a vertical, niche market web-based software stack. If somebody asked me if I was tracking them, I'd chuckle and say "No". Because I'm not. I don't care much what users do, we don't do any data mining, it's your data, so why do I want to look at it?
I'm far too busy fixing bugs and tweaking features to care about mining data! Which brings me to my point: we have extensive logs and can look up every button click, image download, or file upload/download/transfer, going back for years. We've only used that data for fixing bugs, and occasionally for forensics. (EG: at legal or administrative request)
So we aren't "tracking" anyone, but just about everything is logged. And ALL INTERNET BASED PRODUCTS ARE LIKE THAT. I know sure as anything that/. logs my IP address article details, and a few other nifty bits of data everytime I do *anything* *at* *all* here.
News would be proof that Apple is doing something with this data, which I honestly doubt. But even so, there are a million ways you give up your identity every day, online, even if you are "anonymous".
In fact, your actual identity may not matter. Much of what marketers want to know is the various correlations between the different things you are interested in. If you bought a specialty folding bike, what else did you buy? In this light, your name/address is largely irrelevant.
Although I'm a mostly happy Comcast customer at home, my company is also a large customer of a local WISP, giving them 40x what Comcast makes on my home connection.
I only use Comcast for Internet so that I can get to Hulu/Netflix. If/when Comcast becomes a problem, I'll switch to the WISP which is growing like gangbusters and offers speeds comparable to my Comcast.
My guess is that the tactical versions of all of this will use a frequency hoping radio in the "phone" and a dedicated military tower infrastructure with encryption.
Why would this be necessary, or even useful? Why not just layer the encryption on top of an already-well-tested-and-deployed protocol like CDMA?
It's a vastly different world, nowadays. Virtually everywhere, civilian communications networks vastly outperform strictly military networks in ubiquity, reliability, and low cost. You can be sure as anything that the "bad guys" are using their local, civilian networks for their own communications - low cost cell phones, etc - and so are unlikely to try to "take it out". And if they do, so what? There's a multiplicity of networks!
I have an app on my Android phone called "itune radio". With it, I can listen to virtually any radio station, anywhere in the world, in close to real time. When I'm at home, I'm listening via my home Wifi. When on the road, I listen via cellular. At work, it's the office Internet connection.
The specific network(s) in question mean almost nothing.
People have zero brand loyalty or memory in the phone market. They buy whatever they want to, based either on some personal preference or because their cronies got one.
Y're a youngin', ain't ye? Because I remember when this was said about computers! Back when the Apple ][ ruled the roost, Commodore was an industry titan, and Atari was struggling to clear it's stain of "video game company", people switched back and forth routinely! GEM used to be what Windows became, and for the most part, people bought computers for their features, not their compatibility.
Those days, however, are long, long, long gone. Over time, as the ecosystem of computing matured, the apps became richer, deeper, and more integrated. People's preferences and expectations solidified and words like "training curve" and "ROI" became commonplace.
It will happen here, too, and already is starting! Mobile phones are fast becoming a niche software development platform, and vertical business apps, once developed, will be maintained indefinitely for their original platform. Over time, this wild free market will calm down and commoditize , as all markets tend to, and increasingly become stodgy and boring. Pretty soon those vertical apps will be joined by horizontal apps that everybody uses and expects, and when that happens, the wild growth phase of mobile-devices-as-computing-devices will be over.
Microsoft knows this; they spent 10 years anticipating this only to find that it didn't happen all that time because of them. Now, they're playing as hard as they can to re-assert themselves. I would say I wish them luck, but I really don't.
I've spent 20+ years dealing with their horribly designed, insecure, unstable software. I suffered through Windows Mobile 5 and 6. I suffered through every release of Windows from 1.0 forward. (I still have a copy!) I want nothing whatsoever to do with them.
Slashdot Mirror
But what happened to using the best tool for the job? There is a lot of impressive technology in .NET, but is it really the best tool for every job, now and in the future? In my view, it isn't, and can't be.
There are many cases where using the "right tool" offers dramatic performance improvements over the wrong tool. For example, writing large scale structured data storage in C is probably a bad idea, but SQL does the job just wonderfully.
But most cases aren't so clear cut.
At my company, we're a Unix/LAMP shop focusing on PHP and Postgres. Gguess what our server administration scripts run? There's a small amount of BASH, but by and large, it's all.... PHP!
Not that PHP is the ideal language for system administration and coordinating backups or system updates, but it's "good enough" and we're already familiar with it. By having it all written in PHP we get "plenty good enough" performance and the knowledge that any of our developers can pick up the script and immediately start reading it without having to think about the nuances of a different language.
And really, even if there's a 10:1 system performance difference, does it make any difference if the background task completes in 5 seconds instead of 0.5 when it reduces overhead elsewhere?
The "best" tool for the job is often the most conveniently available tool for the job...
I've never had a problem pulling out my laptop for the 5-15 min preflight time.
But then you have to put it away. Under the seat. And then you have to pull it out again, pick up your train of thought... etc Sorry, no.
Let me sit down, open up my lappie, and get to work!
As a late-30s-to-early-40s guy, I wonder what monopoly college frats have on having a bit of fun? What about this kind fun prank makes it "creepy"?
Seriously, WTF?
There's been a raging debate internally as to whether or not we should change to hashed passwords. (for historical reasons, passwords aren't hashed now)
I've pushed for hashing repeatedly, but it's always been downsided by the fact that users are often technological cave-dwellers who have trouble turning their computer ON, let alone not being able to get their password from a support staff.
However, I'm not sure it matters so much, anyway. There are a number of techniques (such as hash tables) that make hashing much less usable, this GPU attack only exacerbates an already bad situation.
I'm of the opinion that anything less than 2 factor authentication is broken now or soon, anyway. I'm in favor of a random, cell phone text tied to the password, myself, except that texts are sometimes delayed. It works like a one-time password and can't meaningfully be broken since the time window of opportunity is far less than the password timeout for trying again.
Done right, this can't even be used to cause a DDOS because, if it's tied to IP addresses, the cracker would have to work 24x7 for a few hundred thousand years to make the window of opportunity, or, use a few hundred thousand IP addresses for a year to do the same in a year.
Since my software company is still mostly regional in nature, it's rare for me to fly more than a 1-2 hour hop at a time. It's barely worth pulling my laptop out at all since I have to wait until about 15-30 minutes until after boarding to begin, and have to put things away 15-30 minutes before actually getting off the plane.
If there was some way that I could sit down, plug in and sign on, and use my computer while the plane is preflighted, taxi, waiting at the taxiway, takeoff, and then final descent from 10,000 to landed and departing the plane, I'd be far, far more likely to pay for the short-ish hops that I tend towards.
And don't give me the "radio interference" crap - there's no evidence at all to support this and it's routinely ignored by anybody in the industry. Think about it: how many routine flyers, do you think, have forgotten to turn off their phone when they sit down, or just didn't bother? How many incidents have occurred as a result?
It's zero, in case you are wondering....
On another note, I routinely send texts while flying my private plane, which I also use for the shorter end of the hops I take. (whichever's cheaper and/or more convenient)
Prepared statements are a decent half-step, but they aren't easily applicable to variable-length queries such as "advanced search" or anything else with optional parameters. It's far too easy to hit one of these walls and fall back into sloppy coding to get around it, negating what little advantage the prepared statements offered.
I don't like prepared statements for the very same reasons. For this reason, we've built our own prepared-statements-like tool that gives us the same advantages of a prepared statement without requiring us to register the statement first.
A preprocessor takes two inputs: the query with string variables embedded, and an array of inputs to match the string variables. In PHP:
$sql="select lastname from users where login = '@login'";
$vars = array('login' => $_REQUEST['login']);
$exec = PrepareQuery($sql, $vars);
The PrepareQuery() function looks for the variables in the sql and replaces them with values passed in, properly sanitized. (DB_escape_string(), etc) The result is very robust and also allows for very dynamic use such as dynamically created queries with optional values, etc.
I've yet to run into a scenario that this model didn't easily handle.
As the CTO of our small company, it bothers me that we use Skype internally. It is very convenient and productive to be able to have snap meetings and group discussions mid-day without having to go through the pain of calling everybody, etc.
But what bothers me is that all this information is going through a 3rd party's servers and I'm pretty paranoid. Ideally, I'd want a service that was cross platform, convenient, and provided a nice mix of calling, video sharing, and text chats across all platforms. Skype does an awful good job at this at the cost of privacy/security issues.
Now my small company does nothing that would be a tremendous surprise if revealed, but it does bother me to give this kind of information to *any* third party.
And when I say "all platforms", that's what I mean: Windows, Mac, Linux, Android, iPhone, Blackberry, etc. which we get now with Skype.
Recently, after reading performance reviews on the Vertex 3, I bought one. The speed is simply amazing! I've been using it as a data-intensive development database server drive. Shortly after buying it, I discovered that there were numerous complaints about the Vertex 2 being unreliable.
To this, I can only say that after about 6 weeks of extremely heavy use as the data partition on a PostgreSQL 8.4 server I've had no issues so far.
Why...why...WHY do people still insist on plain text passwords? Have these people ever heard of a hash? There is 0 reason ever to store a plaintext password, end of story. Anyone who designs a system that stores passwords in plain text should be fired on the spot.
I agree that saving passwords as hashes presents a much better security model, but you are just wrong to think that there is no reason to keep them in plain text.
The real world isn't quite so black and white!
1) It's "unfriendly" to require users to change their password every time. If the user is able to authenticate themselves sufficiently by other means, it may be perfectly legit to give them their password. Sorry, but real users often have a tough time figuring out how to turn on the computer, let alone remember a 12-digit password made of random letters, numbers, symbols and mixed case.
2) Done right, passwords can be invalidated at any time, forcing end users to re-specify a new password. Sufficient logging can also make it pretty clear if you have a security breach on your hands by noting other details of the login process. (EG: Source IP, etc)
3) Many (most?) breaches nowadays don't consist of somebody knowing the passwords, but in the "lost password" process which presents its own security issues - for example, email is sent in plaintext. Against this type of attack, hashes provide no security benefit whatsoever.
4) Debugging: It's nice when, as a developer, you are given access to real, honest-to-god data so that you can code to what's really happening rather than contrived, artificial data sets. Part of working in this type of environment is to be able to access dev copies of databases as users in question. Yes, you can set the passwords as part of the snapshot/replication process, but that does add overhead.
I guess what I'm saying is that storing hashes is like requiring super-strong passwords so that users end up with their password on a sticky note next to the computer: yes you get theoretically better security but it doesn't always work out that way in practice.
Like many decisions, you really have to evaluate this on a case-by-case basis, and you may offset some of the risk by doing things like enforcing the use of SQL prepared statements, or standardizing your data input validation!
And, in all truth, passwords are a terrible, terrible security tool, they just happen to have a better mix of usability, security, and convenience than anything else that's been developed thus far.
I agree that carbon indulgences are bullshit. If you actually give a shit, then consume less. If you don't actually give a shit, then man up and say so, like Mark Cuban did.
I really don't get this point of view, at all, and I say this as a rides-his-bike-to-work-everyday green hippie programmer type who also happens to own a private aircraft. The problem with burning oil is that it releases CO2 into the atmosphere, and your post confirms this.
So why is sequestering CO2 in one place to offset CO2 usage in another, more advantageous place, a bad idea? (shrug)
Listen, we're a LAMP shop, RHEL and/or CENTOS all the way! We've been in business for a decade, and currently have a 20-node cluster for our $2 million/year niche software company, averaging about 20%/year growth, even with the down economy.
And although we're a LAMP shop, I can tell you that hardware/licenses are a tiny part of the costs of our business if the application is structured correctly. ONE of our clients had a dozen servers before switching to our system. Our cluster of (at the time) 6 nodes didn't even register the increase in traffic meaningfully.
It wouldn't have been much different had we gone with Windows Server vs Linux, both can be viable. Licensing costs are a small fraction of the total! There's administration overhead. Power. Bandwidth. Backups. and on, and on. Administration costs dwarf your licensing costs!
Don't avoid Windows to avoid licensing costs, go with Linux because of the fairly significant reduction in Administration costs! Even with 20 nodes and hundreds of clients, thousands of users, we still have only a very part-time admin. (me)
Finite wireless spectrum?!? What are you talking about? Let's talk Mhz:
There is Ghz spectrum between say, 2.4 and 3.4 Ghz, which seems limited. So you might break it out into 1 mhz bands, giving you 1,000 usable frequencies. Or break it more finely,into .1 mhz bands giving you 10,000 usable, or .01 giving you 100,000 frequencies, or...
Take a look at the numbers, to goes on for a LONG time, limited only by our ability to generate better, more accurate crystals to filter out unwanted frequencies.
But wait! There's more! In practical use, most allocated frequencies aren't used most of the time. The vast majority of the regulated spectrum is... dark! It's ALLOCATED but isn't USED much at any specific time, meaning that most of the 'limited' bandwidth is an artifact of a regulatory system constructed during an era when people tuned their radios by jiggering a wire on the surface of a crystal.
Spread spectrum technology, first developed by military for secretive radio communications, send information in short bursts in pseudorandom frequencies. This frquency hopping allows for far more efficient use of existing radio frquencies with minimal disruption. Numerous studies show this type of technology could extend the available bandwidth a billionfold or more.
Sorry, the only limits to wireless bandwidth are our own limits of ingenuity.
You can't technically fix stupid; users that install everything they see will always be the weakest point in system security.
I'd argue that this is NOT the case, just that it's difficult. It's true that given a gun, basically anybody can shoot themselves in the foot. But the basic problem is that there's no easy way to differentiate between a "legit" program that will do you a favor, and one that will do malicious stuff.
The App Store concept solves this problem pretty handily. I'm leery of installing *anything* not found in the App Store simply because I don't want to have to worry about whether or not it will brick my phone or whether I can uninstall it.
Of course, the App Store concept has its own problems, but the Linux Repo model solves this nicely. Repos can be (usually are!) totally open, and for the most part, I just don't install anything I don't find in a few trusted repos. I get all the software I want, I don't have to worry about getting a virus/worm/malware, and getting updates is as easy as ever.
Linux, including Android, gets this right, folks!
I develop HTML5 based robotic heart surgery machines running on top of jQuery beneath AJAX served by node.js off of an Amazon mounted Rackspace Cloud written in Clojure, and I've had it with LCD Screens, CRTs, and so-called editors.
A classic case of using the WRONG TOOL for the job. (I know you were trying to be funny, but still...)
Well that is the answer to his question. Windows is actually quite stable now, on par with Linux.
Well, believe what you wish, I suppose. Over this last weekend, I set up my wife's laptop with Windows 7/64. The number of reboots I had to go through after the O/S install in order to get everything updated was no less than 10 or so, over a few hours. Mind you, this wasn't when setting up drivers, this was *after* I'd loaded the O/S and the drivers. This was just to apply security updates.
I have quite a number of Linux/RedHat/CentOS servers that I maintain, and when I build a new server, I have to reboot exactly one time after loading the O/S to apply updates. Literally, I type a single line as:
yum -y update && shutdown -r now;
That's it. That's the entire sum of the update process, after which I have a fully working, fully updated server with all updates updated.
Limewire has announced a strategic partnership with L1mew1re, wherein any assetts of value of Limewire will be transferred to L1mew1re, which will maintain said assets and lease their use to Limewire.
Limewire's company attorney, while available for comment, was unable to complete a sentence without screaming "bankruptcy, you bastards!!" randomly, mid sentence.
Server Error in '/' Application.
The resource cannot be found.
I guess the list itself is a tech failure, and thus belongs on this list?
FULL INCURSION COMPLETE.
But with the least of four evils (T-Mobile USA) soon to be bought by arguably the greatest of them (AT&T), what do you recommend that smartphone customers who value their freedom do?
What? Four evils? There are other (uhmm) evils out there!
If price is your gig, consider MetroPCS, which happily supports Android phones for just $45/month. Data network is pretty slow, so don't use it for loads of youtube, it's not going to happen. But it's great for email, messaging, iTune remote radio, and navigation.
Metro not available in your area? Well, consider Cricket Wireless. Sporting somewhat better coverage than Metro PCS and somewhat higher prices, they too happily support Android, showing a popular LG Optimus on the home page. (The same phone my wife has; she loves it!)
I switched my family, kids and all, to MetroPCS. My monthly phone costs have dropped by more than half, and I'm not inundated with "phantom charges" which were sprouting like malignant cancers on my monthly cell bills with Verizon Wireless.
Giving dollars to the smaller carriers is a vote for consumer choice, a decision I made recently and I regret it for not a minute.
My recommendation, just stay away.
Unless, it really IS a growing company, at which point you stay as close as humanly possible - there is almost no place as secure as a position in a rapidly growing company, and, as much as I hate to say it, growth costs money!
For example, let's say you have a business where you have terms of "net 30", meaning you submit the bill, and the customer pays within 30 days. Implied is the idea that you deliver service for 30 days before billing. And it takes 30 days for most companies to run the bills for the previous month and figure out what happened and how much was made.
Each of these steps are vulnerable to the "+1" problem, so that it takes 2 months to finish instead of 1. Which means that, for a minimum period of between 90 and 180 days. Up to 180 days (about 6 months) of costs going out the door for an increase in service level unmatched by income.
That, my friends, is where the term "cash poor" comes from, and this kind of "cash poor" is almost exactly where you want to be when jobs are tight.
Don't assume anything without a reason for the assumption.
How do you get severe cost overruns on *rail*?
Trains can carry an entire ton of cargo 500 miles while expending a single gallon of diesel fuel. Because of the extremely steady load, train engines routinely pull a million miles or more (with an overhaul every few hundred thou) before needing replacement.
Further, train tracks cost much less to maintain per mile than roads.
Now, I do realize that I'm referring partially to cargo rail common in the USA, rather than the higher speed passenger trains, but even so, the costs per passenger mile for any train should be dramatically less than car, bus, or plane.
Sounds like corruption at work, if you ask me. (Same as the USA loan crisis)
PS: Forgot the closing "i" tag. Bollucks!
Guys,
Both IOS and Android were written by programmers, who tend to LOG EVERYTHING.
I provide a vertical, niche market web-based software stack. If somebody asked me if I was tracking them, I'd chuckle and say "No". Because I'm not. I don't care much what users do, we don't do any data mining, it's your data, so why do I want to look at it?
I'm far too busy fixing bugs and tweaking features to care about mining data! Which brings me to my point: we have extensive logs and can look up every button click, image download, or file upload/download/transfer, going back for years. We've only used that data for fixing bugs, and occasionally for forensics. (EG: at legal or administrative request)
So we aren't "tracking" anyone, but just about everything is logged. And ALL INTERNET BASED PRODUCTS ARE LIKE THAT. I know sure as anything that /. logs my IP address article details, and a few other nifty bits of data everytime I do *anything* *at* *all* here.
News would be proof that Apple is doing something with this data, which I honestly doubt. But even so, there are a million ways you give up your identity every day, online, even if you are "anonymous".
In fact, your actual identity may not matter. Much of what marketers want to know is the various correlations between the different things you are interested in. If you bought a specialty folding bike, what else did you buy? In this light, your name/address is largely irrelevant.
Although I'm a mostly happy Comcast customer at home, my company is also a large customer of a local WISP, giving them 40x what Comcast makes on my home connection.
I only use Comcast for Internet so that I can get to Hulu/Netflix. If/when Comcast becomes a problem, I'll switch to the WISP which is growing like gangbusters and offers speeds comparable to my Comcast.
My guess is that the tactical versions of all of this will use a frequency hoping radio in the "phone" and a dedicated military tower infrastructure with encryption.
Why would this be necessary, or even useful? Why not just layer the encryption on top of an already-well-tested-and-deployed protocol like CDMA?
It's a vastly different world, nowadays. Virtually everywhere, civilian communications networks vastly outperform strictly military networks in ubiquity, reliability, and low cost. You can be sure as anything that the "bad guys" are using their local, civilian networks for their own communications - low cost cell phones, etc - and so are unlikely to try to "take it out". And if they do, so what? There's a multiplicity of networks!
I have an app on my Android phone called "itune radio". With it, I can listen to virtually any radio station, anywhere in the world, in close to real time. When I'm at home, I'm listening via my home Wifi. When on the road, I listen via cellular. At work, it's the office Internet connection.
The specific network(s) in question mean almost nothing.
People have zero brand loyalty or memory in the phone market. They buy whatever they want to, based either on some personal preference or because their cronies got one.
Y're a youngin', ain't ye? Because I remember when this was said about computers! Back when the Apple ][ ruled the roost, Commodore was an industry titan, and Atari was struggling to clear it's stain of "video game company", people switched back and forth routinely! GEM used to be what Windows became, and for the most part, people bought computers for their features, not their compatibility.
Those days, however, are long, long, long gone. Over time, as the ecosystem of computing matured, the apps became richer, deeper, and more integrated. People's preferences and expectations solidified and words like "training curve" and "ROI" became commonplace.
It will happen here, too, and already is starting! Mobile phones are fast becoming a niche software development platform, and vertical business apps, once developed, will be maintained indefinitely for their original platform. Over time, this wild free market will calm down and commoditize , as all markets tend to, and increasingly become stodgy and boring. Pretty soon those vertical apps will be joined by horizontal apps that everybody uses and expects, and when that happens, the wild growth phase of mobile-devices-as-computing-devices will be over.
Microsoft knows this; they spent 10 years anticipating this only to find that it didn't happen all that time because of them. Now, they're playing as hard as they can to re-assert themselves. I would say I wish them luck, but I really don't.
I've spent 20+ years dealing with their horribly designed, insecure, unstable software. I suffered through Windows Mobile 5 and 6. I suffered through every release of Windows from 1.0 forward. (I still have a copy!) I want nothing whatsoever to do with them.
But hey, that's just me.