Question...as someone who has never made a *BSD firewall, what makes it better to go that way as opposed to buying a Sonicwall or Cisco?
I'd equate it to the difference between being a Windows Admin, and a Unix Admin... The two are worlds apart.
First off, PF syntax is heaven compared to all else. Linux's IPTables syntax is a utter nightmare. Cisco's NAT and ACL syntax is ugly, very limited, so abstracted in syntax and terminology from what it's really doing that it can be impossible to understand without a book of Cisco's own reference material, etc. Juniper's Netscreens are even worse. If anyone tells you otherwise, start asking a few questions about setting-up multi-homed internet service, multicast routing, or trying to determine whether/why a certain connection is being rejected by that 2,000-line ACL rule-set (or failing somewhere else). And this black-box isn't an issue of amateurs who just don't read enough... There really aren't any publications detailing more complex use-cases, and I've exchanged many words with Cisco support managers after multiple level-2 technicians put in explicit writing that some specific multihoming scearios were NOT POSSIBLE on their gear, only to try it out and find it does, in-fact, work exactly as it should.
This isn't something you're likely to hear network admins complain about, because using something better like OpenBSD is never an option they've had, and they know they MUST learn the insane ways of Cisco, to be able to support routers, switches, etc., anyhow.
PF's syntax for ACLs and NAT is dead simple, and as flexible as it can get. What's more, you edit it locally, with your choice of text editor, can syntax check it with a short command, and atomically apply it with all changes (no down-time at all). You've also got unlimited options for commenting it as you choose, making backups, generating it from some dynamic system, including dynamic lists of IPs in a rule that are added/removed by, say, a mail server tracking spammers, or having entire rulesets that are applied only when someone SSHes in to the box, to allow specific services or whatever you want. These are things that network admins DO bemoan on a continual basis... Some network software won't let you insert ACL rules above others (line editing), instead requiring erasing everything below where you want it, then inserting the ACL, then restorting the previous. Others may allow line-editing, but only for permit/deny rules, tossing-out the option of using remarks to properly comment your ACLs.
Network monitoring, debugging, and packet tracing is unimaginably easier. You can run tcpdump, pktstat, or any other utilities RIGHT ON YOUR FIREWALL, telling you EXACTLY what's happening, and where. Easy to filter down to what you want to see, yet can be focused to the point giving you complete packet headers and payloads if you so desire. Cisco pretty recently saw that omitting this functionality can make certain scenarios absolutely impossible to get through, and ASAs now allows generating a pcap/tcpdump/wireshark file, but it must by transferred off to a real computer for analysis in delayed, non-real time.
Anybody using a firewall "appliance" is PROBABLY also using a Unix box to support it in real-time as well... On either side of that ASA / Sonicwall / etc. is a switch configured for "port mirroring", to duplicate ALL that traffic to a Linux box, running SNORT and probably lots of other software, too. That Linux box getting copies of traffic still only provides a modicum of the monitoring, debugging, and reporting options that running your firewall on an actual, full-fledged Unix system can provide, but at least it makes a network admins' difficult job even POSSIBLE to do.
What features are worth the extra expense required to use a computer as a firewall, VS just using a prebuilt ARM one?
While home "routers" really aren't in the same class, there are MANY reasons you'd want something GOO
I heard they JUST got ACPI S3/SUSPEND working... only on x86 (not AMD64) and with a lot of footnotes and exceptions. Sign me up!
I used OpenBSD as my primary desktop for a good number of years, but I wouldn't recommend it. That was back when Linux was a mess, too, so OpenBSD being a bit *more broken* didn't look so bad. Unsupported hardware was a big one... Ported software being ancient as all hell and much of it broken, was a big one, too. It's still a good choice for a firewall (please god kill iptables already, and get PF fully functional on Linux!), but I'm not so sure about that if WiFi is involved, and but it's fallen farther and farther behind over the years, to the point it's hard to recommend for much of anything.
On the plus side, my years of fighting with OpenBSD taught me a lot... The crufty old system and out-dated GCC versions made porting open source programs to proprietary Unices a breeze. The init scripts and overall boot process were/are much easier to learn and understand than anything else. OpenSSH, PF, mksh, and other code to come out of OpenBSD is great, and immensely useful on other platforms.
Natural gas is going to be a HUGE change for this countries infrastructure, both in common usage, as well as emergency failover services.
I'm generally enthusiastic about natural gas, primarily because they can safely run unmanned for extended periods, but let's be honest, there are plenty of problems... Not only do the generators need to be bigger and more expensive, but you've gotta have a back-up plan in case those natural gas lines are either damaged or shut-down.
Propane isn't a direct substitute, but diluting it with fresh air about 40%, it can run unmodified natural gas engines, but then you've got quite a bit of added complexity there. Most importantly, you need a company coming out to refill those propane tanks regularly, and they need to be there right when you need them after natural disasters, in emergency situations where even things like diesel (which are much more common) are very hard to come by.
Compressed natural gas, as used in buses and other portable applications, seems like a better option because it's refueled right from utility lines, but you still need some very large tanks on-site for backup purposes, and some reliable system to cutover without interruption, and the gas company sure isn't going to allow you to connect some half-assed system to their pipes. And when those pipes break, it's not like there's CNG tankers all over the place just waiting to come by and fuel you up, completely the opposite of plentiful diesel tankers, thanks to the use of home heating oil, numerous gas stations, etc.
I'd be all for requiring cell phone companies to have all their cell sites connected to natural gas lines, or else a large propane tank, with a standby generator ready to automatically turn-on whenever power fails. But going the next step, like I outlined above, will be rather expensive, and so rarely needed (unless they use it regularly to supplement grid power during peak) as to be impractical.
Hell, that's GOOD NEWS! People will be frustrated when signing up with companies that impose restrictive terms, while having a super-smooth experience with those who do NOT make any attempt to take away your rights. End result: Those who repect their customers get MUCH more business.
x86 aways wins because anythig useful is put into an x86 core, wholesale. From FPUs to SIMD to virtualization to GPUs. If ARM had any advantages, Intel or AMD would be copying them, and putting them into x86 chips for all to use.
That's how x86 CPUs went from CISC to RISC, and added all the above features, and more.
ARM is a clear example of the MHz myth in action. Their DMIPS/MHz is VASTLY lower than any x86 chip, and their overall MHz/clock speed is much lower, too. ARM has nothing to offer for servers. AMD went the same way with Geode years ago, and went nowhere, too. And even if ARM had some real, technological advantage.... If x64 has taught us anything, it's that backwards compatibilty is worth trillions of dollars to companies, and piss-poor emulation is not a valid substitute.
Well if you don't like Afghanistan, Vietnam, etc, we can go back to the US Civil war, where poorly equipped folks very nearly toppled the US government.
Your faith in technology to win wars isn't at all based in reality. The US Military knows how poorly they do in guerrilla conflicts, annd avoids them at all costs. Nukes aren't useful when the enemy is right next door... guns are.
Knowledgeable people? Cisco HAS THEM, but they sure aren't the guys your call reaches. And then, they disappear for a week, the day after taking your case, and you've got to get it switched to another low-level idiot.
One employer I had woulld rely on Cisco support to tell them how to configure anything they wanted, rather than ensuring good people were in-house, or having a lab environment... I was unlucky enough to have to explain to my boss, over and over, that 5 cisco techs told me the confiiguration I came up with wasn't possible, wouldn't work, and that no equipment they knew of could do it... Since my employer really had no choice but to NOT transition their network at all, they gave me the go ahead to try the configuration after hours, and low and behold, everything worked exactly as I expected, and exactly as they said it absolutely would not.
When Cisco sent me a survey for follow-up, I explained in-detail how incompetent their techs are, and how much of our time (and money) they wasted. After that, I must admit, we got much better support, for a while...
In general, outside support is a nightmare, and the high price of Cisco doesn't make it any better... They're cutting every corner they can.
Most companies are breaking CA labor laws in one way or another, and even if you don't get a positive resolution, you'd get all the facts of the case in official records, where it can be used against them later (Senate H-1B visa hearings?).
Meanwhile, I do believe that companies "can't find" potential employees... Because the recruiting situation is a complete shit-hole, where most jobs are un-advertised, employers only look for people after they need them and insist on immediate placement, NEVER offer things like relocation assistance, and they keep wages low, and keep squeezing more effort and unpaid overtime out of their employees, causing insane turnover which is why they need so many new employees...
I certainly don't change jobs every few years because I enjoy packing up and moving (I'm not a fan of crazy long commutes that have a high likelyhood of resulting in my firey death). I keep switching companies because every last one of them treats even their most valuable employees like crap, though some have been much worse than others.
Much cheaper to convert them to natural gas, which we have lots of. Cars are going to electric at the same time, so there will be much less demand for petroleum.
Editors are fleeing wikipedia like the plague, because nonsensical policies make every conflict a nightmare to deal with, and give vandals and POV pushers a massive edge over good-faith editors.
There is an insane amount of work needed on major Wikipedia articles, which isn't being done, because most of the good editors have already left. All the rest are excuses.
If you care, AT ALL, about power usage, you've just got to stay a bit back from the high-end. My quad-core 2.6GHz AMD CPU has a TDP of 45W. It costs a few dollars more for the low-power series of chips, but not much (unlike Intel's heavy ULV tax) and performs quite well. And this was over a year ago, better stuff with similarly low power is out there.
I think there's something about the makeup of many AMD fans, where they want the high-end, and low-power, and aren't willing to pay a bit more for it.
Your premise really isn't true. Telcom folks certainly had lines with intermittent packet-loss, and TCP was designed to handle it. But when the BSD folks wrote their implementation, they left out the "source-quench" option to signal congestion like most other telecom protocols, and invented the slow-start and exponential back-off on packet-loss that we all know and hate. And since it was BSD-licensed, every other OS out there took that BSD-TCP stack, unmodified, and made it their own, Microsoft included.
The power of legacy equipment has meant that TCP never got fixed, and the bug gets passed forward. And everyone out there with fat pipes has to reinvent their own protocols that have congestion control like TCP once had. One change to the normal TCP stack, and all those "almost-TCP" protocols go away in a flash.
There are no American companies that compete with Huawei. The last American telcom hardware company went out of business long ago. Their competitors are several European firms, like Siemens and Alcatel.
If you'd like to claim that the US government is trying to protect European companies... you not only need proof, but some theory of motive, too.
I can run rootless X11 applications on Windows as well. A seperate compatibilty layer does not fix the problem. And everything staying X11 compatible completely eliminates any need for the added complexity and performance hit of Wayland.
Remove the legacy libs and interface... Fix X11's network transparency, making it perform more like NX... Improve the insane xauth system... make sure GTK and QT still work on it... call it X12 and release it to the public.
Just because maintaining 90% of the legacy code is unnecessary, doesn't mean you need to throw it all away, including the other 10% that works well and 99% of the compatible applications use.
Then they implemented gas pumps with credit card readers. No need to interact with a human running a cash register. Fully automated fuel stations.
Can't have unattended gas pumps, so somebody is still getting paid, they're just sitting around, trying to hawk slim jims, instead of spinning trying to handle everyone's cash.
Besides... credit cards are going down. Last 3 different gas stations I went to, all had dual signage... One column for gas prices if you pay in cash, and one (higher) for people paying with credit cards... CC fees are driving retailers away from cards.
Enjoy the smartphone & tablet bubble while it lasts, but CYA because you never know when it'll come suddenly crashing down. Over night, Apple will go from the king of all companies, to one that is painfully obviously over-valued with stock prices in a decline that seems like it won't ever end. And analysts will rant on about how obvious it was that Apple's non-diversified monoculture was such a bad idea, and claim they said so, before.
That's not to say smartphones or tablets will be going away... just that there's room and money for everyone ONLY while the segment is expanding like crazy. As soon as that growth even slows, the crunch will be sudden and extremely painful, as companies fall daily, and all the hype that helped keep accelerating the bubble suddenly does a 180 and fuels the crash even more quickly. And let's not forget, that the guys left for dead during the bubble will be revered by the business community for their stable strategy that didn't jump headlong into the hype.
Of course there will be plenty of cheap hardware at fire-sale prices to play with, for quite a while. And soon, the world will be restored to a much more sane place, where the distortion of the previous bubble is forgotten, and some other bubble starts growing.
In a non-dystopian future, we're sure to have micro-versions of today's supercomputers, but whether it'll look like a smart phone, AR glasses, or something implanted inside our skulls is something for the next Steve Jobs to market to the gadget sheep of the future.
It's pretty obvious what it'll be. Even now scientists are working on devices that allow blind people to "see", using the nerve endings in their tongue, or whatnot, and developing tech that allows brain activity to be used as an input device. It's all pretty silly right now, but it's quite obvious that input and output devices of today are cumbersome, and the logical conclusion is to have computers wired right to nerves. Don't type or talk, just think... Don't look at the a screen, everything you need to see will be delivered straight to your optic nerve. Whether these future computation devices will really be implanted, or just clip-on to our necks or heads, is an open question.
Transportation is an interesting one, too, as we KNOW it has to change, and we're at the start of a pretty big change right now. The human-sized vacuum tubes in Futurama are probably a good model for the future of transit. Splitting the difference between that, and where we are today, perhaps there will be a proliferation of autonomous, electric-powered, one-man Velomobiles, which just appear when you want them because they got the signal from your implanted computer that you would want to travel somewhere, soon, and drove to your current position. I know they look claustrophobic, but if New York apartments are any indication, we'll ALL live in capsule apartments (with noise cancellation) soon enough, anyhow.
And with cheap, automated cars, comes cheap, automated just-in-time home deliveries of groceries (Welcome back, robotic milk man!), and any other products you could want (if you aren't already printing them at home, or generating them from your replicator...).
Slashdot Mirror
I'd equate it to the difference between being a Windows Admin, and a Unix Admin... The two are worlds apart.
First off, PF syntax is heaven compared to all else. Linux's IPTables syntax is a utter nightmare. Cisco's NAT and ACL syntax is ugly, very limited, so abstracted in syntax and terminology from what it's really doing that it can be impossible to understand without a book of Cisco's own reference material, etc. Juniper's Netscreens are even worse. If anyone tells you otherwise, start asking a few questions about setting-up multi-homed internet service, multicast routing, or trying to determine whether/why a certain connection is being rejected by that 2,000-line ACL rule-set (or failing somewhere else). And this black-box isn't an issue of amateurs who just don't read enough... There really aren't any publications detailing more complex use-cases, and I've exchanged many words with Cisco support managers after multiple level-2 technicians put in explicit writing that some specific multihoming scearios were NOT POSSIBLE on their gear, only to try it out and find it does, in-fact, work exactly as it should.
This isn't something you're likely to hear network admins complain about, because using something better like OpenBSD is never an option they've had, and they know they MUST learn the insane ways of Cisco, to be able to support routers, switches, etc., anyhow.
PF's syntax for ACLs and NAT is dead simple, and as flexible as it can get. What's more, you edit it locally, with your choice of text editor, can syntax check it with a short command, and atomically apply it with all changes (no down-time at all). You've also got unlimited options for commenting it as you choose, making backups, generating it from some dynamic system, including dynamic lists of IPs in a rule that are added/removed by, say, a mail server tracking spammers, or having entire rulesets that are applied only when someone SSHes in to the box, to allow specific services or whatever you want. These are things that network admins DO bemoan on a continual basis... Some network software won't let you insert ACL rules above others (line editing), instead requiring erasing everything below where you want it, then inserting the ACL, then restorting the previous. Others may allow line-editing, but only for permit/deny rules, tossing-out the option of using remarks to properly comment your ACLs.
Network monitoring, debugging, and packet tracing is unimaginably easier. You can run tcpdump, pktstat, or any other utilities RIGHT ON YOUR FIREWALL, telling you EXACTLY what's happening, and where. Easy to filter down to what you want to see, yet can be focused to the point giving you complete packet headers and payloads if you so desire. Cisco pretty recently saw that omitting this functionality can make certain scenarios absolutely impossible to get through, and ASAs now allows generating a pcap/tcpdump/wireshark file, but it must by transferred off to a real computer for analysis in delayed, non-real time.
Anybody using a firewall "appliance" is PROBABLY also using a Unix box to support it in real-time as well... On either side of that ASA / Sonicwall / etc. is a switch configured for "port mirroring", to duplicate ALL that traffic to a Linux box, running SNORT and probably lots of other software, too. That Linux box getting copies of traffic still only provides a modicum of the monitoring, debugging, and reporting options that running your firewall on an actual, full-fledged Unix system can provide, but at least it makes a network admins' difficult job even POSSIBLE to do.
While home "routers" really aren't in the same class, there are MANY reasons you'd want something GOO
I heard they JUST got ACPI S3/SUSPEND working... only on x86 (not AMD64) and with a lot of footnotes and exceptions. Sign me up!
I used OpenBSD as my primary desktop for a good number of years, but I wouldn't recommend it. That was back when Linux was a mess, too, so OpenBSD being a bit *more broken* didn't look so bad. Unsupported hardware was a big one... Ported software being ancient as all hell and much of it broken, was a big one, too. It's still a good choice for a firewall (please god kill iptables already, and get PF fully functional on Linux!), but I'm not so sure about that if WiFi is involved, and but it's fallen farther and farther behind over the years, to the point it's hard to recommend for much of anything.
On the plus side, my years of fighting with OpenBSD taught me a lot... The crufty old system and out-dated GCC versions made porting open source programs to proprietary Unices a breeze. The init scripts and overall boot process were/are much easier to learn and understand than anything else. OpenSSH, PF, mksh, and other code to come out of OpenBSD is great, and immensely useful on other platforms.
I'm generally enthusiastic about natural gas, primarily because they can safely run unmanned for extended periods, but let's be honest, there are plenty of problems... Not only do the generators need to be bigger and more expensive, but you've gotta have a back-up plan in case those natural gas lines are either damaged or shut-down.
Propane isn't a direct substitute, but diluting it with fresh air about 40%, it can run unmodified natural gas engines, but then you've got quite a bit of added complexity there. Most importantly, you need a company coming out to refill those propane tanks regularly, and they need to be there right when you need them after natural disasters, in emergency situations where even things like diesel (which are much more common) are very hard to come by.
Compressed natural gas, as used in buses and other portable applications, seems like a better option because it's refueled right from utility lines, but you still need some very large tanks on-site for backup purposes, and some reliable system to cutover without interruption, and the gas company sure isn't going to allow you to connect some half-assed system to their pipes. And when those pipes break, it's not like there's CNG tankers all over the place just waiting to come by and fuel you up, completely the opposite of plentiful diesel tankers, thanks to the use of home heating oil, numerous gas stations, etc.
I'd be all for requiring cell phone companies to have all their cell sites connected to natural gas lines, or else a large propane tank, with a standby generator ready to automatically turn-on whenever power fails. But going the next step, like I outlined above, will be rather expensive, and so rarely needed (unless they use it regularly to supplement grid power during peak) as to be impractical.
Hell, that's GOOD NEWS! People will be frustrated when signing up with companies that impose restrictive terms, while having a super-smooth experience with those who do NOT make any attempt to take away your rights. End result: Those who repect their customers get MUCH more business.
x86 aways wins because anythig useful is put into an x86 core, wholesale. From FPUs to SIMD to virtualization to GPUs. If ARM had any advantages, Intel or AMD would be copying them, and putting them into x86 chips for all to use.
That's how x86 CPUs went from CISC to RISC, and added all the above features, and more.
ARM is a clear example of the MHz myth in action. Their DMIPS/MHz is VASTLY lower than any x86 chip, and their overall MHz/clock speed is much lower, too. ARM has nothing to offer for servers. AMD went the same way with Geode years ago, and went nowhere, too. And even if ARM had some real, technological advantage.... If x64 has taught us anything, it's that backwards compatibilty is worth trillions of dollars to companies, and piss-poor emulation is not a valid substitute.
Well if you don't like Afghanistan, Vietnam, etc, we can go back to the US Civil war, where poorly equipped folks very nearly toppled the US government.
Your faith in technology to win wars isn't at all based in reality. The US Military knows how poorly they do in guerrilla conflicts, annd avoids them at all costs. Nukes aren't useful when the enemy is right next door... guns are.
Makes no fundamental difference. See libya and others.
Knowledgeable people? Cisco HAS THEM, but they sure aren't the guys your call reaches. And then, they disappear for a week, the day after taking your case, and you've got to get it switched to another low-level idiot.
One employer I had woulld rely on Cisco support to tell them how to configure anything they wanted, rather than ensuring good people were in-house, or having a lab environment... I was unlucky enough to have to explain to my boss, over and over, that 5 cisco techs told me the confiiguration I came up with wasn't possible, wouldn't work, and that no equipment they knew of could do it... Since my employer really had no choice but to NOT transition their network at all, they gave me the go ahead to try the configuration after hours, and low and behold, everything worked exactly as I expected, and exactly as they said it absolutely would not.
When Cisco sent me a survey for follow-up, I explained in-detail how incompetent their techs are, and how much of our time (and money) they wasted. After that, I must admit, we got much better support, for a while...
In general, outside support is a nightmare, and the high price of Cisco doesn't make it any better... They're cutting every corner they can.
You should tell that to guerilla forces, particularly those in afghanistan / pakistan...
You fail at critical thinking skills.
If this happened in California, you should report it to the California Labor Board:
http://www.labor.ca.gov/
Most companies are breaking CA labor laws in one way or another, and even if you don't get a positive resolution, you'd get all the facts of the case in official records, where it can be used against them later (Senate H-1B visa hearings?).
Meanwhile, I do believe that companies "can't find" potential employees... Because the recruiting situation is a complete shit-hole, where most jobs are un-advertised, employers only look for people after they need them and insist on immediate placement, NEVER offer things like relocation assistance, and they keep wages low, and keep squeezing more effort and unpaid overtime out of their employees, causing insane turnover which is why they need so many new employees...
I certainly don't change jobs every few years because I enjoy packing up and moving (I'm not a fan of crazy long commutes that have a high likelyhood of resulting in my firey death). I keep switching companies because every last one of them treats even their most valuable employees like crap, though some have been much worse than others.
Much cheaper to convert them to natural gas, which we have lots of. Cars are going to electric at the same time, so there will be much less demand for petroleum.
Editors are fleeing wikipedia like the plague, because nonsensical policies make every conflict a nightmare to deal with, and give vandals and POV pushers a massive edge over good-faith editors.
There is an insane amount of work needed on major Wikipedia articles, which isn't being done, because most of the good editors have already left. All the rest are excuses.
Neither Motorola nor Cisco make the telcom equipment we're talking about. LTE base stations for example are a big one.
If you care, AT ALL, about power usage, you've just got to stay a bit back from the high-end. My quad-core 2.6GHz AMD CPU has a TDP of 45W. It costs a few dollars more for the low-power series of chips, but not much (unlike Intel's heavy ULV tax) and performs quite well. And this was over a year ago, better stuff with similarly low power is out there.
I think there's something about the makeup of many AMD fans, where they want the high-end, and low-power, and aren't willing to pay a bit more for it.
How about 2 pentium-d CPUs with hyper threading? 8 cores (half of them virtual), almost 4GHz, and yet very much low-end.
Your premise really isn't true. Telcom folks certainly had lines with intermittent packet-loss, and TCP was designed to handle it. But when the BSD folks wrote their implementation, they left out the "source-quench" option to signal congestion like most other telecom protocols, and invented the slow-start and exponential back-off on packet-loss that we all know and hate. And since it was BSD-licensed, every other OS out there took that BSD-TCP stack, unmodified, and made it their own, Microsoft included.
The power of legacy equipment has meant that TCP never got fixed, and the bug gets passed forward. And everyone out there with fat pipes has to reinvent their own protocols that have congestion control like TCP once had. One change to the normal TCP stack, and all those "almost-TCP" protocols go away in a flash.
There are no American companies that compete with Huawei. The last American telcom hardware company went out of business long ago. Their competitors are several European firms, like Siemens and Alcatel.
If you'd like to claim that the US government is trying to protect European companies... you not only need proof, but some theory of motive, too.
I can run rootless X11 applications on Windows as well. A seperate compatibilty layer does not fix the problem. And everything staying X11 compatible completely eliminates any need for the added complexity and performance hit of Wayland.
No, Wayland is throwing out ALL X11 compatibility, and removing network transparency, and all the programs that are designed to support it.
Fluxbox?
Remove the legacy libs and interface... Fix X11's network transparency, making it perform more like NX... Improve the insane xauth system... make sure GTK and QT still work on it... call it X12 and release it to the public.
Just because maintaining 90% of the legacy code is unnecessary, doesn't mean you need to throw it all away, including the other 10% that works well and 99% of the compatible applications use.
Can't have unattended gas pumps, so somebody is still getting paid, they're just sitting around, trying to hawk slim jims, instead of spinning trying to handle everyone's cash.
Besides... credit cards are going down. Last 3 different gas stations I went to, all had dual signage... One column for gas prices if you pay in cash, and one (higher) for people paying with credit cards... CC fees are driving retailers away from cards.
Enjoy the smartphone & tablet bubble while it lasts, but CYA because you never know when it'll come suddenly crashing down. Over night, Apple will go from the king of all companies, to one that is painfully obviously over-valued with stock prices in a decline that seems like it won't ever end. And analysts will rant on about how obvious it was that Apple's non-diversified monoculture was such a bad idea, and claim they said so, before.
That's not to say smartphones or tablets will be going away... just that there's room and money for everyone ONLY while the segment is expanding like crazy. As soon as that growth even slows, the crunch will be sudden and extremely painful, as companies fall daily, and all the hype that helped keep accelerating the bubble suddenly does a 180 and fuels the crash even more quickly. And let's not forget, that the guys left for dead during the bubble will be revered by the business community for their stable strategy that didn't jump headlong into the hype.
Of course there will be plenty of cheap hardware at fire-sale prices to play with, for quite a while. And soon, the world will be restored to a much more sane place, where the distortion of the previous bubble is forgotten, and some other bubble starts growing.
Google may have competitors in the search space, but it has practically none in the advertising space, ever since Google bought-out doubleclick.
Capsule Apartment Link:
http://www.designgonewild.com/img/content2008/tokyo_capsule_inn_hotel.jpg
http://3.bp.blogspot.com/_p9bTjaEtKuc/S-lkH3xo6XI/AAAAAAAADjI/fLLhO4M52v8/s1600/13084_743343_capsule_hotel_0.jpg
It's pretty obvious what it'll be. Even now scientists are working on devices that allow blind people to "see", using the nerve endings in their tongue, or whatnot, and developing tech that allows brain activity to be used as an input device. It's all pretty silly right now, but it's quite obvious that input and output devices of today are cumbersome, and the logical conclusion is to have computers wired right to nerves. Don't type or talk, just think... Don't look at the a screen, everything you need to see will be delivered straight to your optic nerve. Whether these future computation devices will really be implanted, or just clip-on to our necks or heads, is an open question.
Transportation is an interesting one, too, as we KNOW it has to change, and we're at the start of a pretty big change right now. The human-sized vacuum tubes in Futurama are probably a good model for the future of transit. Splitting the difference between that, and where we are today, perhaps there will be a proliferation of autonomous, electric-powered, one-man Velomobiles, which just appear when you want them because they got the signal from your implanted computer that you would want to travel somewhere, soon, and drove to your current position. I know they look claustrophobic, but if New York apartments are any indication, we'll ALL live in capsule apartments (with noise cancellation) soon enough, anyhow.
And with cheap, automated cars, comes cheap, automated just-in-time home deliveries of groceries (Welcome back, robotic milk man!), and any other products you could want (if you aren't already printing them at home, or generating them from your replicator...).