No, they use gigabit and 10G ethernet. Infiniband is the opposite of cheap commodity hardware. Infiniband is expensive per port and not commodity.
Google has a two vendor policy, I know some of their network gear for gig-e and 10G-e is Force10. Google and Force10 are both involved in the 802.3ba (40G and 100G), Force10 is on the IEEE committee and Google is one of the customers with demand, they may have a seat on the committee I don't really know all the members.
The cost is a fallacy. But even assuming that was true, how many industries does Open Source allow?
ebay? Amazon? Google? Redhat? IBM? Many other shops gain efficiency from using Opensource (certainly in finance and healthcare).
Or to make a bad car analogy: How many billions in buggy whip manufacturers or buggy makers were lost to the automobile? hmmm? Or is the efficiency of the car a net gain on the horse drawn carriage?
Rute is a "Rute is a technical reference and teaching tool for new GNU/Linux users as well as advanced administrators". It is available online and in book format. It is copyright 2002, so it isn't terribly out of date.
It is a good curriculum for linux users or administrators. If you don't like the way it is setup you could get the online copy and change it.
The only thing I'd be worried about in terms of datedness is LPI/RHCE certification. I doubt it would get you through RHCE as it now covers SELinux as well which is not really covered in Rute.
"Non-IP networks are dying? Must tell that to makers of Infiniband cards, who are carving out a very nice LAN niche and are set on moving into the WAN market. Also need to tell that to xDSL providers, who invariably use ATM, not IP. And if you consider IP to mean IPv4, then the US Government should be informed forthwith that its migration to IPv6 is "dead". Oh, and for satellite communication, they've only just got IP to even work. Since they weren't using string and tin cans before, I can only assume most in use are controlled via non-IP protocols and that this will be true for a very long time. More down-to-earth, PCI's latest specs allows for multiple hosts and is becoming a LAN protocol. USB, FireWire and Bluetooth are all networks of a sort - Bluetooth has a range of a mile, if you connect the devices via rifle."
You are conflating physical/layer2 with layer 3 which has the IP. Almost every transport you mentioned competes with Ethernet (not IP) and almost all of those transports can haul IPv4 or IPv6- because of how ubiquitous IP networks are.
FC and Infiniband can haul IP and be hauled by IP (encapsulation look into it).
You may nit away but RHEL 3 was essentially RH 9. RHEL 4 is essentially Fedora Core 3. RHEL 5 will likely essentially be FC 6 or so... The base software is the same. Bug fixes, support, ISV certification etc. are the value of RHEL.
The Debian nomenclature doesn't quite work as I originally indicated, but it is pretty close.
FC is closer to a test for RHEL than some people like to consider. A very polished, useable, great test.
Consider the following from the fedoraproject.org website:
"Why should I pay for Red Hat Enterprise Linux when Fedora Core is free? What is the relationship between Fedora Core and Red Hat Enterprise Linux?
Both Fedora Core and Red Hat Enterprise Linux (RHEL) are open source. Fedora Core is a community project and serves as the base platform on which RHEL is built. The cost of RHEL comes from the subscription, which provides assorted certifications and support for additional architectures, as well as 7 years of enterprise support. Red Hat also enhances its RHEL offerings with additional software and with certification programs. Despite the misinformation that others spread, the base RHEL distribution is open source, and the complete source code can always be downloaded from [WWW] Red Hat's FTP servers. "
This is a good thing, for Redhat and what is good for Redhat is generally good for linux. Redhat pays many kernel developers and contributes huge amounts of opensource code- enterprise class opensource code.
Since Fedora Core is basically RHEL testing or unstable ( to try to fit the Debian nomenclature, I guess rawhide is unstable, FC is testing, RHEL is stable ), Redhat needs to be able to control where Fedora Core is going and what goes in. Partly to maintain quality control, partly to make sure Fedora goals incorporate the Redhat goals, partly for their legal department to not freak out.
Until another linux company becomes as central to linux in business as Redhat, what is good for Redhat is good for linux.
I think this will have limited impact for people who use Fedora Core as a home desktop (or even business). Probably none they will notice.
For those that use other distributions, this will have almost no impact, because the things they use in their distributions that Redhat contributes will still be high quality and GPL.
1) In most companies, the job of IS is to help the company make money. So I can see where you have a difference of opinion. Sometimes the job is to make it easier or possible for the company to make money.
2) IS (like security) is a cross functional group and is involved with every group in the company at some level. Because your job is to make their job easier. Computers are like a lever or other tool to make work easier, you help them figure out how to use this force multiplier or lever (or make it easier to use the lever).
3) If you are overloaded you need better time management goals and prioritization. Sometimes it has to get worse before it gets better. If you implement some things that save administration time with top priority, you may get more back logged at first, but the queue will clear as the time savers kick in. You need to switch from reactive mode to proactive.
Making the switch from reactive to proactive takes time, money, smarts and a smooth political hand.
Boot from cd update BIOS. I've done this about 10 times for different motherboards.
I've even done it just from linux using dos bootdisks from the internet (I don't have dos anymore): 1) download awdflash and bios for mobo 2) download bootdisk image from bootdisk.com 3) loop mount disk image 4) delete some files to make room, pare down the autoexec.bat, put awdflash and bios on mounted disk image 5) umount disk image and burn as a bootable cd (you can even use something like K3b or xcdroast to do this from a gui) 6) boot from cd, and then flash bios.
It gets niftier...
Say you have to do this in a cluster. Keep that dos boot disk image and automate it some (awdflash has some command line switches, batch file etc).
Then put that image on your PXE server as a bootable option. Change your DHCP server and PXE boot, then you can remotely upgrade bios on 100s or thousands of identical machines. Be careful with this part or you can make some thousand dollar paper weights.
If you are running windows, many modern mobo manufacturers have bios updaters that run in windows.
Unless you really have only point to point applications, look into MPLS frame or an MPLS provider. Often you can get away with less bandwidth because you abandon hub and spoke model. If you VOIP it is cheaper to MPLS, if not it might be more expensive:(
1) MPLS contracts usually come with clear and enforceable SLAs. That will help mitigate your downtime and control the vendor.
2) MPLS can hand off on DSL or frame or all sorts of ways depending on the provider.
3) is is multi-point to multi-point and you don't have to keep up with the config (just the ip scheme and routing really).
4) QoS
4a) if you like it enough you can use it for VOIP- converged networks can save you some coin.
5) There is competition in that space, so you can get good deals, and likely better service.
The local loop may still be sbc, but at least you'll be calling a better tech support group at another company.
If you want to stay with your current tech:
use standard vendor tactic: competition.
For example, call your sales rep, let them know you are un-happy and thinking about moving providers. Mention any direct comptitors (Time Warner, MCI, etc...), a name drop never hurts when negotiating.
also try to get your contract and check for SLAs. If you have no enforceable service level agreements for availability (uptime) and qos (latency at least), either renegotiate or take your requirements elsewhere.
Wrong!! Don't spread mis-information.
FC 3 is a beta for RHEL 4.
See http://www.fedorafaq.org/
RHEL 3 was already out when FC2 was out. RHEL 3 is really based on RH 9.
http://fedora.redhat.com/about/history/
So to wrap up.
RHEL 2 based on RH 7.2 7.2.9 or 7.3 (dunno)
RHEL 3 based on RH9
RHEL 4 based on FC 3
-A
and for the OP: whitebox is okay.
Do you control the mesh of routers? Are they mesh routers (wireless type)? or are they many routers with connections to each other (deployed in a mesh)?
I think you are asking the wrong question. You may need QoS for applications. You may need a mesh for high-availability or redundancy or efficiency. You probably don't need to conflate the two.
QoS is to help in situations where bandwidth is used up. It drops, queues or buffers non-important traffic and forwards higher priority traffic first. If the network is solid, QoS is most helpful when bandwidth is used (or at least approaches capacity).
Most routing protocols can incorporate bandwidth, delay and other network indicators: EIGRP does and OSPF can be configured to do so. You will need a routing protocol if you want to manage a "mesh of routers" without too much administrative pain.
And now add policy based routing. You can combine a routing protocol with policy based routing to route high priority packets over a prefered network route, but if that route goes the protocol can route them another way.
A routing protocol gives you redundancy and multiple paths (and the ability to take advantage of multiple paths). QoS avoids congestion, bandwidth and latency problems.
_
So if you have end to end QoS and routers with a capable routing protocol and maybe some policy based routing, your problem is fixed.
But you asked about mesh routers (like firetide wireless?)... and wireless really doesn't have QoS standards- wireless QoS is kinda all proprietary now. So my best advice is:
You should check with your sales engineer for your networking gear, if they can't answer- find a different vendor.
I know several CCIE's who can answer this type of thing in their sleep.
-A
Oh and if you are asking this question and seriously positing MPLS as an answer, then you haven't done your homework. MPLS is not for wireless. MPLS is not something you implement or buy for your network- it is generally for carrier networks. Carriers can offer you some type of hand off and carry your traffic over an MPLS based network- but that won't fix your network, just traffic over the wan.
If you posted more specific info, it would be easier to point you along in the right direction.
And yes, this type of question is interesting to me, but this particular question is not conceived well in my opinion. And yeah, I do this stuff for fun and work.
The cookbook series...
on
Linux Cookbook
·
· Score: 2, Insightful
I have the Cisco Cookbook and I like it.
It doesn't give you domain knowledge like some of O'Reilly's other books (I'm looking at you BIND and DNS). What the Oreilly cookbooks generally give you is a nice task or goal based instruction set with some explanation.
It is a little like a how-to for problems or tasks.
There are 43 (according to the search on Oreilly.com) books in the series:
The chinese probably are using the cisco GSRs. If you google for GSR IPv6 you'll see a couple places with IPv6 and the GSR in action (abiliene?) and some with Juniper to GSR Ipv6 connections.
-A
While the idea that the chinese stole the router and hacked in IPv6 is nice, it is much easier to believe they bought a couple GSRs that support IPv6.
No developer should have root on PRODUCTION boxes.
The process should be:
development happens on development box (workstation, server whatever). Developers may have root on this- if they do, they manage it, OS hardware and all. Developers will use sudo if anyone else is responsible for the server hardware and OS. This should never be exposed to untrusted networks.
QA stage: if you are poor or small, do this against the development box. If not this should be a seperate QA box. This should be managed by QA team. If the sysadmin is the same, the sysadmin should hold root, qa team may sudo, developers should not be accessing this box directly (except in emergency, then they will be sheperded by QA). This should also not be exposed to untrusted networks unless you have and excellent (and obeyed) security policy and review.
Production: only the sysadmin has root, noone else should have access. The sysadmin publishes to production- using the release that QA approves. Highest security policy applies here.
If your QA and dev team are the same, collapse development and QA- but trust me keep production seperate.
If you mean Point of Sale (which is what most people mean by POS check it via google if you don't believe me):
Look at wwww.linux-pos.org.
You need some more detail in your question as well. Barcode? Web based? Cash register?
What Point of Sale features do you need?
if you really mean Purchase Order System, the options are kinda slim in the Open Source world. Compiere maybe your only option.
www.compiere.org
I would guess, that really with 5 people you will spend more time on the Purchase Order System than just having either a dedicated purchaser or good manangement and oversight.
Oh and if you didn't mean open source, then.... you must be new around here.
That is why I covered size and density and network economic efficiency (which is the cost of the infrastructure taking into account # of users and amount users pay for network features).
to cover japan in a 3 G network we'll say it takes X cell stations and it will cover all N Million Japanese.
to cover the US (unscientifically a zillion times the size) it would take Zillion x X cellstations and it will cover all N Million Americans.
Upgrading the Japanese network requires retrofitting X cellstations, while upgrading the US network requires zillion x X cellstations.
Very few networks actually cover the entire united states, because of the related problem of:
polulation density.
Japan is packed with people, and overall there are more people per square mile-
the US when averaged out, is not very dense. Sure there are some dense areas, and that is where the tests and pilot programs and prototypes are tried out...
but this impacts cost. So if you could deploy a network and it would be used pretty thoroughly all the way through with users paying for it, you would have a good network economic efficiency (in terms of dollar earned per dollar spent on infrastructure).
The US with it's low density tends towards poor network economic efficiency (except on the coasts) while Japan has high density and tends towards good network economic efficiency.
This higher efficiency in turn makes it easier to make enough profit which make it worthwhile to upgrade the network to offer more services to sell to your clients.
Cisco is in an interesting position in spite of buying linksys, they will face competition from 3com (who is positioned below them in the market now) and from above by Juniper. Both Juniper and 3Com are getting into the access router comptetion.
I'd like to know if 3com has some or any of the convergence features (voip, ipv6, qos, multicast) that new networks often need. Cisco access routers may cost, but it is easy to implement a network with some excellent modern features. Cisco has a modular product line that will allow you to implement without VOIP or other features and then later add it easily. It is also easy to find people familiar with cisco IOS command line. You may pay less for a 3com router, and then waste time configuring it or finding out you can't configure the features you need.
For Juniper a different set of problems (as there are a few people out there that know JunOS and there is a training infrastructure for it like Cisco). Juniper may have the convergence features (I don't know I haven't looked at the product line), but it is more likely as they are moving from the top down.
Cisco will face some interesting comptetion, but I'm sure they will respond- which can only be good for the customer.
-A
Disclaimer: I am Cisco certified and like using their networking equipment.
1) they don't want users to need root for hardware (but do want users to need the admin to install certain software). This info is in the PDF. They already see that needing root for hardware install or configuration needs to be worked around.
2) the design is a hybrid or amalgamation of thin and fat client, trying to cherry pick the best of both:
applications run on local systems
software and data cached on local disk
central management and configuration of nodes
they call it a cached client technology
3) they have a plan for laptops. Stateless... instantiation, sync... things that sound vague, but they seem to have a plan because this stuff is considered in the howto. There are some notes in the how-to covering the different types of clients:
" diskless clients, which boot directly from a snapshot stored on the server
caching clients, which boot from a copy of a snapshot, cached locally on a hard drive.
Live CD clients, which boot from a copy of a snapshot burned onto a CD
thick clients, which don't use snapshots and must be maintained by another means. "
The idea has some very cool potential for a business or network situation. I can't imagine this is ready for production, but it could be soon.
In spite of Ericsson pulling out, I think Bluetooth adoption will speed up. Maybe they are getting out of the game at the right time for them, sometimes the money is in a product before commodification.
The reason I think Bluetooth adoption will speed up is it is on most of the Apple pc products now. That happened with USB also. At that time PS/2 (or adb) was still the favorite connector for keyboards and mice, now on Mac and many PC's USB is the way.
As a further prognostication, I think Bluetooth could be the high end mouse/keyboard/PDA/cell phone connector of choice down the road. While USB is handy, the new iMac shows that lacking a swarm of cables can be a nice feature.
It is kind of a pain. You need to adjust QoS settings to cause congestion or delay.
2 ways:
One mark the traffic you want to be delayed and then pump a bunch of traffic through the pipe at the same time. Apply QoS to the unmatched traffic (say a ttcp stream is good). This will provide a real world latency and will be hard to predict how much latency.
The second way is to manually mess with the low latency queing settings for an interface (decrease queue size is one way), beware this will foobar your performace so keep a backup config or don't accidentally put the router into production. This will let you do more predictable latency tests, but you still may need a stream of data to really bork up the latency.
You can always do the bandwidth command on an interface and introduce pinhole congestion as well (may add latency), but that may not be what you are looking for... and I'm sure occured to you already.
-Andrew
more info available on www.cisco.com
http://www.cisco.com/en/US/tech/tk39/tk824/technol ogies_configuration_example09186a008009461f.shtml
and search for QoS as well, and then use the techniques in an inverse manner.
Slashdot Mirror
No, they use gigabit and 10G ethernet. Infiniband is the opposite of cheap commodity hardware. Infiniband is expensive per port and not commodity.
Google has a two vendor policy, I know some of their network gear for gig-e and 10G-e is Force10. Google and Force10 are both involved in the 802.3ba (40G and 100G), Force10 is on the IEEE committee and Google is one of the customers with demand, they may have a seat on the committee I don't really know all the members.
The cost is a fallacy. But even assuming that was true, how many industries does Open Source allow?
ebay? Amazon? Google? Redhat? IBM? Many other shops gain efficiency from using Opensource (certainly in finance and healthcare).
Or to make a bad car analogy: How many billions in buggy whip manufacturers or buggy makers were lost to the automobile? hmmm? Or is the efficiency of the car a net gain on the horse drawn carriage?
I would use Rute by Paul Sheer:
http://linux.2038bug.com/rute-home.html
http://rute.2038bug.com/index.html.gz
Rute is a "Rute is a technical reference and teaching tool for new GNU/Linux users as well as advanced administrators". It is available online and in book format. It is copyright 2002, so it isn't terribly out of date.
It is a good curriculum for linux users or administrators. If you don't like the way it is setup you could get the online copy and change it.
The only thing I'd be worried about in terms of datedness is LPI/RHCE certification. I doubt it would get you through RHCE as it now covers SELinux as well which is not really covered in Rute.
Hey, that is my password too!!
Pro-rec not available, but fortunately there was a mirror.
. htm
This guy wrote about it 5 years ago on the web.
http://moozeek.de/mirrors/articles/over_the_limit
It is informative. And something to show your friends who say, "yeah, but that album isn't as loud. The newer albums are better."
"Non-IP networks are dying? Must tell that to makers of Infiniband cards, who are carving out a very nice LAN niche and are set on moving into the WAN market. Also need to tell that to xDSL providers, who invariably use ATM, not IP. And if you consider IP to mean IPv4, then the US Government should be informed forthwith that its migration to IPv6 is "dead". Oh, and for satellite communication, they've only just got IP to even work. Since they weren't using string and tin cans before, I can only assume most in use are controlled via non-IP protocols and that this will be true for a very long time. More down-to-earth, PCI's latest specs allows for multiple hosts and is becoming a LAN protocol. USB, FireWire and Bluetooth are all networks of a sort - Bluetooth has a range of a mile, if you connect the devices via rifle."
You are conflating physical/layer2 with layer 3 which has the IP. Almost every transport you mentioned competes with Ethernet (not IP) and almost all of those transports can haul IPv4 or IPv6- because of how ubiquitous IP networks are.
FC and Infiniband can haul IP and be hauled by IP (encapsulation look into it).
Andrew Tridgell's rzip wasn't on there either.
http://samba.org/junkcode/
Tridge is one of the smart guys behind samba. And rzip is pretty clever for certain things. Just ask google.
You may nit away but RHEL 3 was essentially RH 9. RHEL 4 is essentially Fedora Core 3. RHEL 5 will likely essentially be FC 6 or so... The base software is the same. Bug fixes, support, ISV certification etc. are the value of RHEL.
The Debian nomenclature doesn't quite work as I originally indicated, but it is pretty close.
FC is closer to a test for RHEL than some people like to consider. A very polished, useable, great test.
Consider the following from the fedoraproject.org website:
"Why should I pay for Red Hat Enterprise Linux when Fedora Core is free? What is the relationship between Fedora Core and Red Hat Enterprise Linux?
Both Fedora Core and Red Hat Enterprise Linux (RHEL) are open source. Fedora Core is a community project and serves as the base platform on which RHEL is built. The cost of RHEL comes from the subscription, which provides assorted certifications and support for additional architectures, as well as 7 years of enterprise support. Red Hat also enhances its RHEL offerings with additional software and with certification programs. Despite the misinformation that others spread, the base RHEL distribution is open source, and the complete source code can always be downloaded from [WWW] Red Hat's FTP servers. "
This is a good thing, for Redhat and what is good for Redhat is generally good for linux. Redhat pays many kernel developers and contributes huge amounts of opensource code- enterprise class opensource code.
Since Fedora Core is basically RHEL testing or unstable ( to try to fit the Debian nomenclature, I guess rawhide is unstable, FC is testing, RHEL is stable ), Redhat needs to be able to control where Fedora Core is going and what goes in. Partly to maintain quality control, partly to make sure Fedora goals incorporate the Redhat goals, partly for their legal department to not freak out.
Until another linux company becomes as central to linux in business as Redhat, what is good for Redhat is good for linux.
I think this will have limited impact for people who use Fedora Core as a home desktop (or even business). Probably none they will notice.
For those that use other distributions, this will have almost no impact, because the things they use in their distributions that Redhat contributes will still be high quality and GPL.
1) In most companies, the job of IS is to help the company make money. So I can see where you have a difference of opinion. Sometimes the job is to make it easier or possible for the company to make money.
2) IS (like security) is a cross functional group and is involved with every group in the company at some level. Because your job is to make their job easier. Computers are like a lever or other tool to make work easier, you help them figure out how to use this force multiplier or lever (or make it easier to use the lever).
3) If you are overloaded you need better time management goals and prioritization. Sometimes it has to get worse before it gets better. If you implement some things that save administration time with top priority, you may get more back logged at first, but the queue will clear as the time savers kick in. You need to switch from reactive mode to proactive.
Making the switch from reactive to proactive takes time, money, smarts and a smooth political hand.
Check out this book:
http://www.everythingsysadmin.com/
it has invaluable practical advice for all of these problems. It is not specifically a technical book.
-A
Make a boot floppy image and burn it to cd.
Boot from cd update BIOS. I've done this about 10 times for different motherboards.
I've even done it just from linux using dos bootdisks from the internet (I don't have dos anymore):
1) download awdflash and bios for mobo
2) download bootdisk image from bootdisk.com
3) loop mount disk image
4) delete some files to make room, pare down the autoexec.bat, put awdflash and bios on mounted disk image
5) umount disk image and burn as a bootable cd (you can even use something like K3b or xcdroast to do this from a gui)
6) boot from cd, and then flash bios.
It gets niftier...
Say you have to do this in a cluster. Keep that dos boot disk image and automate it some (awdflash has some command line switches, batch file etc).
Then put that image on your PXE server as a bootable option. Change your DHCP server and PXE boot, then you can remotely upgrade bios on 100s or thousands of identical machines. Be careful with this part or you can make some thousand dollar paper weights.
If you are running windows, many modern mobo manufacturers have bios updaters that run in windows.
-A
Unless you really have only point to point applications, look into MPLS frame or an MPLS provider. Often you can get away with less bandwidth because you abandon hub and spoke model. If you VOIP it is cheaper to MPLS, if not it might be more expensive :(
1) MPLS contracts usually come with clear and enforceable SLAs. That will help mitigate your downtime and control the vendor.
2) MPLS can hand off on DSL or frame or all sorts of ways depending on the provider.
3) is is multi-point to multi-point and you don't have to keep up with the config (just the ip scheme and routing really).
4) QoS
4a) if you like it enough you can use it for VOIP- converged networks can save you some coin.
5) There is competition in that space, so you can get good deals, and likely better service.
The local loop may still be sbc, but at least you'll be calling a better tech support group at another company.
If you want to stay with your current tech:
use standard vendor tactic: competition.
For example, call your sales rep, let them know you are un-happy and thinking about moving providers. Mention any direct comptitors (Time Warner, MCI, etc...), a name drop never hurts when negotiating.
also try to get your contract and check for SLAs. If you have no enforceable service level agreements for availability (uptime) and qos (latency at least), either renegotiate or take your requirements elsewhere.
-A
Wrong!! Don't spread mis-information. FC 3 is a beta for RHEL 4. See http://www.fedorafaq.org/ RHEL 3 was already out when FC2 was out. RHEL 3 is really based on RH 9. http://fedora.redhat.com/about/history/ So to wrap up. RHEL 2 based on RH 7.2 7.2.9 or 7.3 (dunno) RHEL 3 based on RH9 RHEL 4 based on FC 3 -A and for the OP: whitebox is okay.
Do you control the mesh of routers? Are they mesh routers (wireless type)? or are they many routers with connections to each other (deployed in a mesh)?
I think you are asking the wrong question. You may need QoS for applications. You may need a mesh for high-availability or redundancy or efficiency. You probably don't need to conflate the two.
QoS is to help in situations where bandwidth is used up. It drops, queues or buffers non-important traffic and forwards higher priority traffic first. If the network is solid, QoS is most helpful when bandwidth is used (or at least approaches capacity).
Most routing protocols can incorporate bandwidth, delay and other network indicators: EIGRP does and OSPF can be configured to do so. You will need a routing protocol if you want to manage a "mesh of routers" without too much administrative pain.
And now add policy based routing. You can combine a routing protocol with policy based routing to route high priority packets over a prefered network route, but if that route goes the protocol can route them another way.
A routing protocol gives you redundancy and multiple paths (and the ability to take advantage of multiple paths). QoS avoids congestion, bandwidth and latency problems.
_
So if you have end to end QoS and routers with a capable routing protocol and maybe some policy based routing, your problem is fixed.
But you asked about mesh routers (like firetide wireless?)... and wireless really doesn't have QoS standards- wireless QoS is kinda all proprietary now. So my best advice is:
You should check with your sales engineer for your networking gear, if they can't answer- find a different vendor.
I know several CCIE's who can answer this type of thing in their sleep.
-A
Oh and if you are asking this question and seriously positing MPLS as an answer, then you haven't done your homework. MPLS is not for wireless. MPLS is not something you implement or buy for your network- it is generally for carrier networks. Carriers can offer you some type of hand off and carry your traffic over an MPLS based network- but that won't fix your network, just traffic over the wan.
If you posted more specific info, it would be easier to point you along in the right direction.
And yes, this type of question is interesting to me, but this particular question is not conceived well in my opinion. And yeah, I do this stuff for fun and work.
I have the Cisco Cookbook and I like it.
& sp -f=ISO-8859-1&search=Go&sp-t=cat_search&sp-q=cookb ook&sp-k=Books&sp-i=1
It doesn't give you domain knowledge like some of O'Reilly's other books (I'm looking at you BIND and DNS). What the Oreilly cookbooks generally give you is a nice task or goal based instruction set with some explanation.
It is a little like a how-to for problems or tasks.
There are 43 (according to the search on Oreilly.com) books in the series:
http://search.atomz.com/search/?sp-a=sp1000a5a9
I'd like to get a copy of the linux one to peruse.
-A
The 12000 series supports IPv6 and so does the very model you point out.
/ ps 5014/prod_release_note09186a0080199977.html
Check the release notes:
http://www.cisco.com/en/US/products/sw/iosswrel
The chinese probably are using the cisco GSRs. If you google for GSR IPv6 you'll see a couple places with IPv6 and the GSR in action (abiliene?) and some with Juniper to GSR Ipv6 connections.
-A
While the idea that the chinese stole the router and hacked in IPv6 is nice, it is much easier to believe they bought a couple GSRs that support IPv6.
No developer should have root on PRODUCTION boxes.
The process should be:
development happens on development box (workstation, server whatever). Developers may have root on this- if they do, they manage it, OS hardware and all. Developers will use sudo if anyone else is responsible for the server hardware and OS. This should never be exposed to untrusted networks.
QA stage: if you are poor or small, do this against the development box. If not this should be a seperate QA box. This should be managed by QA team. If the sysadmin is the same, the sysadmin should hold root, qa team may sudo, developers should not be accessing this box directly (except in emergency, then they will be sheperded by QA). This should also not be exposed to untrusted networks unless you have and excellent (and obeyed) security policy and review.
Production: only the sysadmin has root, noone else should have access. The sysadmin publishes to production- using the release that QA approves. Highest security policy applies here.
If your QA and dev team are the same, collapse development and QA- but trust me keep production seperate.
-A
If you mean Point of Sale (which is what most people mean by POS check it via google if you don't believe me):
.... you must be new around here.
Look at wwww.linux-pos.org.
You need some more detail in your question as well.
Barcode? Web based? Cash register?
What Point of Sale features do you need?
if you really mean Purchase Order System, the options are kinda slim in the Open Source world. Compiere maybe your only option.
www.compiere.org
I would guess, that really with 5 people you will spend more time on the Purchase Order System than just having either a dedicated purchaser or good manangement and oversight.
Oh and if you didn't mean open source, then
-A
That is why I covered size and density and network economic efficiency (which is the cost of the infrastructure taking into account # of users and amount users pay for network features).
-A
because networks take infrastructure...
to cover japan in a 3 G network we'll say it takes X cell stations and it will cover all N Million Japanese.
to cover the US (unscientifically a zillion times the size) it would take Zillion x X cellstations and it will cover all N Million Americans.
Upgrading the Japanese network requires retrofitting X cellstations, while upgrading the US network requires zillion x X cellstations.
Very few networks actually cover the entire united states, because of the related problem of:
polulation density.
Japan is packed with people, and overall there are more people per square mile-
the US when averaged out, is not very dense. Sure there are some dense areas, and that is where the tests and pilot programs and prototypes are tried out...
but this impacts cost. So if you could deploy a network and it would be used pretty thoroughly all the way through with users paying for it, you would have a good network economic efficiency (in terms of dollar earned per dollar spent on infrastructure).
The US with it's low density tends towards poor network economic efficiency (except on the coasts) while Japan has high density and tends towards good network economic efficiency.
This higher efficiency in turn makes it easier to make enough profit which make it worthwhile to upgrade the network to offer more services to sell to your clients.
-E
BTW... The 15" PB has PCMCIA.
Cisco is in an interesting position in spite of buying linksys, they will face competition from 3com (who is positioned below them in the market now) and from above by Juniper. Both Juniper and 3Com are getting into the access router comptetion.
I'd like to know if 3com has some or any of the convergence features (voip, ipv6, qos, multicast) that new networks often need. Cisco access routers may cost, but it is easy to implement a network with some excellent modern features. Cisco has a modular product line that will allow you to implement without VOIP or other features and then later add it easily. It is also easy to find people familiar with cisco IOS command line. You may pay less for a 3com router, and then waste time configuring it or finding out you can't configure the features you need.
For Juniper a different set of problems (as there are a few people out there that know JunOS and there is a training infrastructure for it like Cisco). Juniper may have the convergence features (I don't know I haven't looked at the product line), but it is more likely as they are moving from the top down.
Cisco will face some interesting comptetion, but I'm sure they will respond- which can only be good for the customer.
-A
Disclaimer: I am Cisco certified and like using their networking equipment.
If you read the article, you will see that:
1) they don't want users to need root for hardware (but do want users to need the admin to install certain software). This info is in the PDF. They already see that needing root for hardware install or configuration needs to be worked around.
2) the design is a hybrid or amalgamation of thin and fat client, trying to cherry pick the best of both:
applications run on local systems
software and data cached on local disk
central management and configuration of nodes
they call it a cached client technology
3) they have a plan for laptops. Stateless... instantiation, sync... things that sound vague, but they seem to have a plan because this stuff is considered in the howto. There are some notes in the how-to covering the different types of clients:
" diskless clients, which boot directly from a snapshot stored on the server
caching clients, which boot from a copy of a snapshot, cached locally on a hard drive.
Live CD clients, which boot from a copy of a snapshot burned onto a CD
thick clients, which don't use snapshots and must be maintained by another means.
"
The idea has some very cool potential for a business or network situation. I can't imagine this is ready for production, but it could be soon.
-A
In spite of Ericsson pulling out, I think Bluetooth adoption will speed up. Maybe they are getting out of the game at the right time for them, sometimes the money is in a product before commodification.
The reason I think Bluetooth adoption will speed up is it is on most of the Apple pc products now. That happened with USB also. At that time PS/2 (or adb) was still the favorite connector for keyboards and mice, now on Mac and many PC's USB is the way.
As a further prognostication, I think Bluetooth could be the high end mouse/keyboard/PDA/cell phone connector of choice down the road. While USB is handy, the new iMac shows that lacking a swarm of cables can be a nice feature.
-A
It appears the US Navy do not have a perfect record:
http://www.lutins.org/nukes.html
Seems like weapons and coolant accidents happen often enough, there are over twenty in the section labelled submarines and ships.
These appear to be confirmed on other sites (including wikipedia) by googling "US Navy Nuclear Accidents".
It doesn't refute all of your argument, but the last sentence is suspect.
-A
It is kind of a pain. You need to adjust QoS settings to cause congestion or delay. 2 ways: One mark the traffic you want to be delayed and then pump a bunch of traffic through the pipe at the same time. Apply QoS to the unmatched traffic (say a ttcp stream is good). This will provide a real world latency and will be hard to predict how much latency. The second way is to manually mess with the low latency queing settings for an interface (decrease queue size is one way), beware this will foobar your performace so keep a backup config or don't accidentally put the router into production. This will let you do more predictable latency tests, but you still may need a stream of data to really bork up the latency. You can always do the bandwidth command on an interface and introduce pinhole congestion as well (may add latency), but that may not be what you are looking for... and I'm sure occured to you already. -Andrew more info available on www.cisco.com http://www.cisco.com/en/US/tech/tk39/tk824/technol ogies_configuration_example09186a008009461f.shtml
and search for QoS as well, and then use the techniques in an inverse manner.