Re:Still for sale though-can't FF, blame DVDForum
on
The VHS is Dead
·
· Score: 3, Informative
Letting the Media conglomerates decide when you can fast-forward is part of the original deal to get a license to build DVD players. Google was not immediately helpful, but the truth is out there...
This "I want my software now, management is too stupid to see this" is completely bogus.
Just how credible is it that with two days to go, you're going to take a 1000$ package, and it will actually accellerate anything? If all you've done is look at the kickass demo, then it will take a couple of weeks/months to learn the application. You might be someone who knows this app, great then, Are you able and willing to teach it to the rest of the staff so that it is productive? How much is that training going to cost? Is it a good idea to invest in this product rather than the twenty competitors on the market? Why? because YOU guy says it's kickass after seeing a demo?
So we maintain one PC configuration for Joe, another for Mary, another for Jack, etc... 100 different configurations... something's broken, and you call support to fix you cheap ass machine. three days later we find that your critical app replaced some system library which conflicted with what other apps were expecting. 100 different configs, means 100 different sets of conflicts. That is going to be really, really expensive after a while.
"Heck it's only 1000$"... yeah... for one guy. Now do you want it forever? or just for one guy for two days. Why would I get it just for one out of 15 developers if it's such a great tool. oh... 15K$. You want to keep it forever right? so it's really 15K$ + 3K per year maintenance, so over five years, you're spending 27K$. Then there's the support staff who have to install it and keep it up to date, so that the next random vulnerability in your 1K$ package doesn't shutdown development with two days to go before a deadline.
Then there is "well yeah, when you use X" you have to include this library with the product, oh and there's royalties there. Or, no... product X's run-time app doesn't support SP2, what do you mean the server is running SP2? Damn! package Y needs SP2. there goes the deadline!
When somebody wants to run something, it is a commitment that an organization makes to a product. Gauging the level of commitment required, and all the ramifications of it, is not something you're gonna do with "I saw the demo and it Rocks", or even "I've used this at my last job a sites 'R US, and my and my brother jeb thought it was fab! I thought it was so great that I bought stock in the company."
Figuring out whether those decisions make sense is what managers do. Get over the sophomoric crap, and give managers information to figure make a decision, rather than fumes.
You don't need a provider to do deploy VOIP. The only essential thing that a provider is giving you is an interface into the POTS network. Once everyone is on the internet, you'll just be able to "phone greg@home.com" and a currently non-existent protocol will resolve that to whatever communication Greg has on hand, by talking only with Greg's own equipment, not that of any provider. The internet is Peer 2 Peer.
Sure, you will still be doing Voice over IP, but it won't be any kind of huge revenue generator for VOIP companies, and, as commercial entities, they will shrivel and die. But I wouldn't worry, they probably have a good ten to twenty years of good times before people figure that out.
That you feel compelled to report your experience only emphasizes that it was unexpected and unusual. It is always good to hear about companies who understand and can help. The fact is, they aren't common, and that kind of support is extremely expensive for the company to provide. The tech has to know about all these third party apps, and have testbeds to try things out with them.
There is also the possibility that you got the one guy on the support desk who knows his ass from eyeball, and the rest of them would have sent you flying. I hope it is more than that.
Experience in my organization with a load balancer problem: Eighteen months of talking to nice gentleman with south asian accents and funny schedules, two complete unit replacements shipped and installed, a software upgrade or two. Turned out to be a (to be fair, fairly obscure) DNS configuration problem. This was from a major vendor (no need to embarass them here) and of course my staff wasn't without blame here either. A large vendor had me turn off anti-virus before diagnosing a problem with their mail server, a company that makes a lovely proprietary language for web applications (interpreter built in java) had us downgrade our servers, and remove SMP support from our kernel ("we don't support multiple processors on linux, we don't support RH x.y, only x.y-1") The best one was... I bought software from another vendor for linux in November. In April of this year, they decided to change their pricing policy. the new price was, wait for it... ten times the price the previous november, and the november price had five digits in it, and the support costs went in line with the new pricing. Oh, and they dropped linux support too. We dumped them.
In general, all support sucks (though you get lucky once in a while, and it is a blessing when you do.)
I'd rather roll my own luck, training my own staff, than depend on hit and miss commercial support. I'm sure some pencil pusher will insist that that is terribly expensive, but they are dead wrong. It is far more expensive to deploy hundreds of disparate system with only the vaguest clue of how they run, (and little fragile procedures that reduce analysts to just typists) and then have to run to get support on them all.
Good IT staff is a strategic necessity for any large organization, because bad IT staff can easily cause orders of magnitude of difference in costs on projects, without any improvement in deliverables. Most organizations don't get that, and can't figure out what good IT staff look like. They hire low skilled staff for full-timers, and contract out all the projects because low skilled people cannot handle it. This is just wrong, because contractors never will have as much organizational knowledge, and they don't see the big picture (aren't paid to) so they implement the spec (and the specs are always perfect, right;-) which is exactly what a contractor must do. But it is bad for the organization. The real argument against outsourcing is the loss of institutional understanding, the loss of strategic knowledge. Folks will eventually figure that out, but it will take a few years.
Hell, I can't tell what anybody's worth in an interview, no matter how long. It's really hard, and it's hit and miss.
You've got some linux binary which is doing something odd. You can track down how the source was built, and build it yourself, with -g or a couple of printf's. Heck, just running strace on it often provides a lot of information. That's because the UNIX API is pretty compact, and folks with only a modicum of experience will be able to grok it.
I've never heard of anyone running anything like strace on windows. I suspect that the reason is because the control flow and system calls are so complicated that not too many people will be able to make head of tails of the output, so it isn't much use. Windows programs are BIG. linux ones tend to be much smaller (and do less) so they are just plain easier to figure out (the normal advantage of modularity.) Linux packages will often be built by a bunch of small programs held together with some scripting. That is much easier to figure out than some monolithic ubercode.
Again, it comes down to barrier to entry, if the code is smaller and easier to figure out, and there is more information available (source code is documentation too.) then there is a bigger chance that a reasonably motivated geek will acquire significant skills, and perhaps even insight. On windows, you don't have a chance, you just kind of ride the bear and pray.
I agree. It makes it much harder to sell people on open source, but it is much better to control expectation, and be able to meet realistic targets along the way, than it is to tell them they'll be reducing costs in a year, and watch the project spin out of control because everything was under-estimated, and the windows admins are trying to torpedo the thing anyways, so the project fails.
We need a few, slow, well thought outand documented successful transitions to demonstrate that it will work in a large organization. Trying to ram it through by being overly optimistic is going to be bad for everyone.
it is that admins NEED someone external to blame when the shit does hit the fan.
I see this idea all the time, and it is completely bogus. The admins are responsible for fixing the problem. Period. Are you going to empower them, or shackle them?
When we call up MS with an Exchange problem, they want us to de-activate our virus scanner, because they don't support that. In real life, there is usually a whole mess of interoperating bunches of code: firewall exchange Anti-Virus OS app environment. No vendor will stand up and say, when you have an actual multi-vendor configuration, "this is my problem and I am going to fix it." The admin always has to prove absolutely that you are on a completely supported configuration (don't get me started on "compatibility matrices") and then run tests for each vendor, and figure out which one to sit on in any given situation.
What you really need is in-house admins who understand how the software works, in order to pin down where the problem lies in order to know where to apply pressure.
That whole analysis process is much more difficult on windows because it is much more obfuscated and complicated (layer after layer of compatibility, and unfathomable binaries) than linux (no binaries, can inspect everything, tend to have less depth and breadth in individual programs.)
It is really hard to have good windows admins, not because their aren't a lot of smart people running windows, but because those smart people have nothing to work with to develop anything beyond the most rudimentary skills.
If you run open source linux, (not canned binaries, and not applications built on ten layers of middleware) people who have the potential will grow skilled with time. but it is a long term thing. Skilled people are a long term investment.
The payoff is going to be dramatic, but it isn't going to be quick. In any big shop today, there will be a small army of unix/linux guys, and a much larger army of windows people. There's more windows out there, and they take more people to run anyways, so you always end up with more windows admins.
If you're a shop with administrators with 20 years experience on windows, those folks are going to be quite cranky about moving to linux. Downright fearful, in fact. We had a few admins who were concerned enough that they considered retiring a little early rather than having to face upgrading from windows NT 4.0 to XP. Their job is to know exactly what to do when a client comes to them, and their "knowledge" is hard-won by experience. It will take a few years for such people to retrain to the same level of expertise on linux. It's deeply different. For a large shop:
count on a migration period of about five years.
Train the admins, make them your friends.
Transition back-office stuff first, so that admins cut their teeth away from users prying eyes.
For the desktops, try an easy one first, like firefox. Let simmer for a year or two.
wean people slowly off of desktop apps, with more and more web applications, making sure they work with firefox.
Then try a bigger one: open office. This is the really big one. take it slow, careful, and thoroughly researched (like how to transition Joe's macro's etc...)
After that, users will barely notice when windows is swapped out and replaced. They'll already be used to firefox & openoffice. the linux thing won't be a big deal, especially if it's on KDE.
That, as far as I can gather, is Munich's plan. It is an exceedingly rational one. The main point is that the first two or three years are going to be more expensive. You're going to be paying all the MS taxes and adding massive training costs for techs, and parallel deployments of linux boxes. It's got to be more expensive at first.
You have to appreciate the complete mind warp we are asking windows people to do. After the admin's are onside (this is the really tough part.) They need to get comfortable (they've done some implementations, they don't look for D: anymore to install stuff from. They google for help, and don't think the only source of true knowledge is a vendor) And finally, they have to get attuned (When we need a new application, their first reaction is to check out sf.net & freshmeat, and spend some time evaluating open source before looking at commercial stuff.)
This is seriously relearning how to think kind of stuff. It will take a few years to adjust to. Rolling out desktops has to be the last bit on the end, once all the techies are comfortable and attuned. Because when a client comes to them, they are the expert. The techies will feel really uncomfortable if they are not comfortable.
So like the realistic plan is something like... training for a year, with some pilots, then another year doing some server stuff. That second year will drag into two. Third year you start handle the tougher apps (those without ready analogues), move the clients over to open office, and train the front-line user desk staff. (roll out desktops for the techies.) year four, you do the desktop rollout. I seriously believe that end users in large shops will not require much training at all. All the complications in linux arise from administration tasks: installing software, configuring services, network connections, driver support. All of this stuff is handled by techis in a big shop. So all that is left to users is navigating in the file browser, which, honestly, is not going the take much training.
So in year five, most of your licensing costs drop to 0. Remote administration, for managing applications, configuration, and patches become much easier and simpler (cron + apt-get for debian stable users.), and viruses are something others worry about. So the ratio of admins to users will be able to increase, and you can re-task admins for other fun stuff.
nobody wants airline scheduling and capacity info either, boring stuff...
Air Canada claims that "espionage on a massive scale" took place at the home of WestJet vice president Mark Hill. It wants to search WestJet's records for evidence that WestJet used information from an Air Canada employee-only website to plan its flight schedule and expansion.
...
In court documents, Hill has admitted that he did access the Air Canada employee-only website using the password and PIN of a former Air Canada employee now working for WestJet. Air Canada claims WestJet logged onto the website thousands of times between May 15, 2003 and March 19, 2004.
The site provides all of Air Canada's ticket sale information.
WestJet says "the information on the website was never used by WestJet in any way related to its business decisions." But Air Canada alleges WestJet used the information to change its routes and improve its expansion plans to better compete with Canada's largest airline.
so... to all catholics/protestant/muslims out there, it is incumbent upon them to prove that Santa Claus, the Easter Bunny, Thor, Zeus, Neptune, Poseidon, elves, dragons, mermaids, the Loch Ness monster, and innumerable thousands of Indian gods which said theist considers mythical do not exist.
Thought experiment: Order 10000 PC's. time how long it takes to get them installed, with power, network cabling, and cooling, in racks, and installed with the same OS.
Second thought experiment. Imagine the systems are built out of modular bricks that are identical to deskside servers. so that they can sell exactly the same hardware in anywhere from 2 to 512 processors by just plugging the same standard bricks together, and they all get the same shared memory, and run one OS. Rack after rack after rack. That is SGI's architecture. It is absolutely gorgeous.
So they install twenty of the biggest boxes they have, and network those together.
$/buck ? I dunno. Is shared memory really a good idea? Probably not. but it is absolutely gorgeous, and no-one can touch them in that shared memory niche that they have.
uhm... Well 2560 motherboards, 'cause their quad-cpu... Altix is the SGI C-bricks that used were built to house 4 IA64 cpu's per brick. otoh... no... really it really is 20 machines with 512 processors each, because the memory is globally shared (all processors have access to all the memory, albeit at different latency and performance: NUMA (Non Uniform Memory Access). and a single linux kernel is running on the whole thing.
I see it as a lot safer. Any time you reduce the amount of head movement required to navigate, you are going to increase the driver's situational awareness.
If the dash board includes all the mirrors (multi-function screens), then the driver has to look in a lot fewer directions. Put the car in reverse and the three in dash screens show: left, middle and right rear views. All the views can be seen at once, rather than having to crane the head in different directions to see them all. Many older people especially have difficulty with the mobility required to safely back up a vehicle.
If you are looking in your rear view mirror in order to pass, or because or an interesting event is occurring there (event left as an excercise to the reader:-) then the closer the angle of the head is to looking at the windshield, the more likely you are to see the car you are about to rear-end.
The dash in the Toyota Echo was moved to the centreline in order to reduce the distance the eyes have to move to view the instruments. You can put the mirror displays wherever makes the most sense. Could even be in a HUD on the windshield, or There might be a whole new meaning to driving glasses, with important information projected on the screen there, regardless of where you are looking.
As for the parts being expensive, Electronics used to be expensive, but they are, naturally, very, very cheap. They will get far cheaper as volume increases, and you'll be able to get your cameras at the local NAPA shop. Most of the sensors have perfectly reasonable value in terms of engine control, and should be dirt cheap in volume. Mechanical systems that are expensive and far more custom. Most sensors are relatively cheap already, are solid state, and pretty durable. Compare Dual Holley carbs vs. fuel injectors with electronic sensors, and figure out which stays tuned longer, which gets better mileage (performs better air-gas mixture regulation), and which has lower total cost (once the maintenance is included in the mix.) I think you can add a truckload of sensors for the amount of labour you save.
Cars should include redundant sensors that vote, just like on more expensive vehicles, so that when one sensor fails, the system diagnoses it, and one can get it replaced at leisure without having the car misfire in the meantime.
Cars are going to get simple the way PC hardware is getting trivial. It is cheaper to throw out boards than to troubleshoot them in the PC world. Diagnosing a car should be a matter of understanding what fourty or fifty sensors are saying. Computers are probably better at that than humans, and will be able to give us reasonable diagnoses. Older cars with more primitive computers tend to give garbage diagnoses (not enough data...)
Digital cars will be a great thing. It's not just flying car stuff, but basic, useful improvements every geek would love:
Those big protrusions out the side of the car... you know, mirrors? Replace them with a pinhole sized camera in the high mounted brake light. Not only does it shave weight, but look at the air flow advantages.
Put all the LED's in some central part of the car and just pipe the light out to the headlights and tail lights. Switch the signals centrally, so you can use less bulbs (light all three brake lights with a single (plus backup) LED, a single signal light, etc...) The mounting for the lights in the back is then much lighter, and there is no need to route copper power wires back there. Reduced, power, reduced components, reduced weight.
Like the minivan rear-view cameras, improved visibility, no blind spots, given enough cameras.
Use infrared cameras to improve night vision (assuming HUD display instead of LCD in dash.)
The cameras are a prerequisite for the self-driving cars in the future (sensors for the computers)
All digital dashboard (series of LCD's for the whole instrument panel.) Then you can have three camera views while backing up. and see the speedometer when going forward. This will also make it cheaper to have "sport gauges" and can have dozens of other sensors that just don't fit into a normal dash, but only show up on the displays when they have something important to share. (oil pressure, oil volume, oil temperature, oil viscosity, tire pressure, tire temperature, brake fluid level, coolant level, coolant pressure) All of that could be made much more cheaply.
Instead of just "check engine"... how about a dashboard that says: "um, excuse me, this is your engine, I'm running OK, but cylinder 4 has poor ignition, probably needs a new spark plug lead." or "Hi, you've cracked a cylinder head, kiss your wallet goodbye."
used to be true for sure. at 3.6, if you want to run "testing/sarge", it's pretty easy now. I installed one a few weeks ago, and apt-get against the debian repositories "just works."
I even tried swapping repositories back and forth and it never got confused.
The one thing that is messy is the kernel. The knoppix kernel documentation is just wrong. It says it is a straight debian kernel, but there are many fiddly bits added (ie. ipw2100 wlan, wavelan, & winmodem drivers, etc...) but the rest is pretty straight forward.
boot knoppix up, under the penguin menu, select Network/Internet->/dev/modem setup, then there are checkboxes, one of which is for "unsupported winmodem".
YMMV.
It's been a while for me (5 years ago, last time I was in SASH, for the IRIX aware), but all the UNIX recovery tools I saw booted you into a shell. Knoppix is as if it booted straight into the equivalent of CDE (KDE) and puts an icon of each of your partitions on the screen, that you can just click on to mount and navigate in GUI fashion. Sure, you still need to understand chroot to be able to fix things properly, but it is a heck of a lot easier to use than the older methods. You can check for doc on the internet with a browser (you can GOOGLE!), repartition with a GUI tool.
A problem you don't have with UNIX (because the supported hardware variety is tiny) that is really a killer on PC's is hardware detection. Typically, if you are running a distribution that is a little older, you won't be able to detect some stuff, and you did some magic to get it working. Keeping your rescue disks uptodate with your magic is far more hassle than just downloading the latest knopppix every six months.
That article is over a year old things have changed significantly:
article claims all knoppix is german by default. No, there are two flavours of images you can download -EN (English) and -DE (deutsch umm that's german in german to non german speakers:-) ).iso
talks about 3.2 (understandably). 3.6 is out, and it includes kernel 2.6.7, (you have to invoke knoppix26 on the command line) which is pretty close to the latest and greatest.
in 3.6, there are softmodem drivers. Some of them are truly free, others are free versions of linuxant drivers, which are limited to 14.4 kbps (you pay for a license key to run at full speed.) They work (this was on a redhat 8 system, though.)
Assuming the VA, as a big hospital provider in the US, would use them... that would make "good" RFID tags really attractive. so if an American goes south, rather than just taking his wallet, they'll want to stab the person to dig up the tag. It is small, so it will take a while to find.
" they'll turn it off by default and make you pay extra for the privilege of QoS. "
keep that thought. I want live in finland and want to phone my Aunt in Australia. What are the chances that they use the same ISP? you want QoS? What are the chances that whatever your ISP does will make the slightest difference once it leaves the realm? Oh.. the ISP's will need to co-operate and all be nice enough to treat eachother's QoS traffic with the respect it needs. OK, what's their cut? oh, you need to bill by the bit, oh, by the kilometer too, oh... welcome to the phone company's world. forget free calls, forget the "because it's cheap" argument because it won't be. Got that?
Now let's be Vonage. Forget QoS, don't bother talking to any ISP's. You get to market quicker, have far wider "coverage" (don't care who the ISP is), can charge less than half what the other guy does, and still make a killing.
The point is not the last mile. Many times downloads proceed at 6 kB/s when the link and the server at the other end are both capable of far more. In that situation, there is a choke point somewhere on the net. Your download bandwidth will be limited by the chokepoint. If you get more priority at the chokepoint, you get faster downloads. In the extreme case of your ISP being badly provisioned, the idea is to get a greater share of the T1.
The article also held out the hope that this is the tip of the iceberg. Imagine videoconferencing in HD with stereo sound, half a dozen end-points. now 6-20 mb/s of bandwidth is about right. that is a reasonably attractive amount of bandwidth for a downloader. given multi-point connections, and a conference lasting a few hours, how is this different from a bit-torrent session?
Priority is priority. It will be abused. plain human nature. Now folks will say "but we won't let people do that" ! How? This will become a new hack. You've got NAT'ing firewalls at both ends, and arbitrary software (oh, you want to lock down MY computer?! ) hopefully, these streams will be encrypted, so how in your preferred deity's name will you be able to differentiate encrypted compressed multi-media conference from... oh... an encrypted compressed movie being shared.
This is way too hard a problem. It will never be cheap, the folks, like Vonage, that don't bother with it, will be far cheaper and kill anyone who tries to do QoS. Consumers will just learn that that is the way it is, and most of the time, it will be great, but the reliability will not be the same. tough. It's a converged network, that is what it means.
how does one "reduce latency"... hmm... I would think that that would cause the entire network to forward packets faster, more consistently for that traffic. So.. if there is no network congestion, then don't tag the packets, they'll only slow down. If there are bottlenecks, who is going to get a better transfer rate, with or without the QoS flags?
Slashdot Mirror
Letting the Media conglomerates decide when you can
fast-forward is part of the original deal to get a license to build
DVD players. Google was not immediately helpful, but the truth is out there...
I read somewhere that ownership of the right to sue Microsoft was explicitly excluded when Novell sold WordPerfect to Corel.
This "I want my software now, management is too stupid to see this" is completely bogus.
Just how credible is it that with two days to go, you're going to take a 1000$ package, and it will actually accellerate anything? If all you've done is look at the kickass demo, then it will take a couple of weeks/months to learn the application. You might be someone who knows this app, great then, Are you able and willing to teach it to the rest of the staff so that it is productive? How much is that training going to cost? Is it a good idea to invest in this product rather than the twenty competitors on the market? Why? because YOU guy says it's kickass after seeing a demo?
So we maintain one PC configuration for Joe, another for Mary, another for Jack, etc... 100 different configurations... something's broken, and you call support to fix you cheap ass machine. three days later we find that your critical app replaced some system library which conflicted with what other apps were expecting. 100 different configs, means 100 different sets of conflicts. That is going to be really, really expensive after a while.
"Heck it's only 1000$"... yeah... for one guy.
Now do you want it forever? or just for one guy for two days. Why would I get it just for one out of 15 developers if it's such a great tool. oh... 15K$. You want to keep it forever right? so it's really 15K$ + 3K per year maintenance, so over five years, you're spending 27K$. Then there's the support staff who have to install it and keep it up to date, so that the next random vulnerability in your 1K$ package doesn't shutdown development with two days to go before a deadline.
Then there is "well yeah, when you use X" you have to include this library with the product, oh and there's royalties there. Or, no... product X's run-time app doesn't support SP2, what do you mean the server is running SP2? Damn! package Y needs SP2. there goes the deadline!
When somebody wants to run something, it is a commitment that an organization makes to a product. Gauging the level of commitment required, and all the ramifications of it, is not something you're gonna do with "I saw the demo and it Rocks", or even "I've used this at my last job a sites 'R US, and my and my brother jeb thought it was fab! I thought it was so great that I bought stock in the company."
Figuring out whether those decisions make sense is what managers do. Get over the sophomoric crap, and give managers information to figure make a decision, rather than fumes.
how long before grandma gets off POTS? Until "everyone" has it, you're going to need these intermediaries. I'll stick with my estimate.
Thanks for those who mentioned SIP. I've heard of it, but had no idea what it did.
I want to see two knights in armour with lances go at
eachother on the field of mortal combat, on segways.
(sorry, must've been something I ate...)
You don't need a provider to do deploy VOIP. The only essential thing that a provider is giving you is an interface into the POTS network. Once everyone is on the internet, you'll just be able to "phone greg@home.com" and a currently non-existent protocol will resolve that to whatever communication Greg has on hand, by talking only with Greg's own equipment, not that of any provider. The internet is Peer 2 Peer.
Sure, you will still be doing Voice over IP, but it won't be any kind of huge revenue generator for VOIP companies, and, as commercial entities, they will shrivel and die. But I wouldn't worry, they probably have a good ten to twenty years of good times before people figure that out.
That you feel compelled to report your experience only emphasizes that it was unexpected and unusual. It is always good to hear about companies who understand and can help. The fact is, they aren't common, and that kind of support is extremely expensive for the company to provide. The tech has to know about all these third party apps, and have testbeds to try things out with them.
;-) which is exactly what a contractor must do. But it is bad for the organization. The real argument against outsourcing is the loss of institutional understanding, the loss of strategic knowledge. Folks will eventually figure that out, but it will take a few years.
There is also the possibility that you got the one guy on the support desk who knows his ass from eyeball, and the rest of them would have sent you flying. I hope it is more than that.
Experience in my organization with a load balancer problem:
Eighteen months of talking to nice gentleman with south asian accents and funny schedules, two complete unit replacements shipped and installed, a software upgrade or two. Turned out to be a (to be fair, fairly obscure) DNS configuration problem. This was from a major vendor (no need to embarass them here) and of course my staff wasn't without blame here either. A large vendor had me turn off anti-virus before diagnosing a problem with their mail server, a company that makes a lovely proprietary language for web applications (interpreter built in java) had us downgrade our servers, and remove SMP support from our kernel ("we don't support multiple processors on linux, we don't support RH x.y, only x.y-1") The best one was... I bought software from another vendor for linux in November. In April of this year, they decided to change their pricing policy. the new price was, wait for it... ten times the price the previous november, and the november price had five digits in it, and the support costs went in line with the new pricing. Oh, and they dropped linux support too. We dumped them.
In general, all support sucks (though you get lucky once in a while, and it is a blessing when you do.)
I'd rather roll my own luck, training my own staff, than depend on hit and miss commercial support. I'm sure some pencil pusher will insist that that is terribly expensive, but they are dead wrong. It is far more expensive to deploy hundreds of disparate system with only the vaguest clue of how they run, (and little fragile procedures that reduce analysts to just typists) and then have to run to get support on them all.
Good IT staff is a strategic necessity for any large organization, because bad IT staff can easily cause orders of magnitude of difference in costs on projects, without any improvement in deliverables. Most organizations don't get that, and can't figure out what good IT staff look like. They hire low skilled staff for full-timers, and contract out all the projects because low skilled people cannot handle it. This is just wrong, because contractors never will have as much organizational knowledge, and they don't see the big picture (aren't paid to) so they implement the spec (and the specs are always perfect, right
Hell, I can't tell what anybody's worth in an interview, no matter how long. It's really hard, and it's hit and miss.
You've got some linux binary which is doing something odd. You can track down how the source was built, and build it yourself, with -g or a couple of printf's. Heck, just running strace on it often provides a lot of information. That's because the UNIX API is pretty compact, and folks with only a modicum of experience will be able to grok it.
I've never heard of anyone running anything like strace on windows. I suspect that the reason is because the control flow and system calls are so complicated that not too many people will be able to make head of tails of the output, so it isn't much use. Windows programs are BIG. linux ones tend to be much smaller (and do less) so they are just plain easier to figure out (the normal advantage of modularity.) Linux packages will often be built by a bunch of small programs held together with some scripting. That is much easier to figure out than some monolithic ubercode.
Again, it comes down to barrier to entry, if the code is smaller and easier to figure out, and there is more information available (source code is documentation too.) then there is a bigger chance that a reasonably motivated geek will acquire significant skills, and perhaps even insight. On windows, you don't have a chance, you just kind of ride the bear and pray.
I agree. It makes it much harder to sell people on open source, but it is much better to control expectation, and be able to meet realistic targets along the way, than it is to tell them they'll be reducing costs in a year, and watch the project spin out of control because everything was under-estimated, and the windows admins are trying to torpedo the thing anyways, so the project fails.
We need a few, slow, well thought outand documented successful transitions to demonstrate that it will work in a large organization. Trying to ram it through by being overly optimistic is going to be bad for everyone.
I see this idea all the time, and it is completely bogus. The admins are responsible for fixing the problem. Period. Are you going to empower them, or shackle them?
When we call up MS with an Exchange problem, they want us to de-activate our virus scanner, because they don't support that. In real life, there is usually a whole mess of interoperating bunches of code: firewall exchange Anti-Virus OS app environment.
No vendor will stand up and say, when you have an actual multi-vendor configuration, "this is my problem and I am going to fix it." The admin always has to prove absolutely that you are on a completely supported configuration (don't get me started on "compatibility matrices") and then run tests for each vendor, and figure out which one to sit on in any given situation.
What you really need is in-house admins who understand how the software works, in order to pin down where the problem lies in order to know where to apply pressure.
That whole analysis process is much more difficult on windows because it is much more obfuscated and complicated (layer after layer of compatibility, and unfathomable binaries) than linux (no binaries, can inspect everything, tend to have less depth and breadth in individual programs.)
It is really hard to have good windows admins, not because their aren't a lot of smart people running windows, but because those smart people have nothing to work with to develop anything beyond the most rudimentary skills.
If you run open source linux, (not canned binaries, and not applications built on ten layers of middleware) people who have the potential will grow skilled with time. but it is a long term thing. Skilled people are a long term investment.
If you're a shop with administrators with 20 years experience on windows, those folks are going to be quite cranky about moving to linux. Downright fearful, in fact. We had a few admins who were concerned enough that they considered retiring a little early rather than having to face upgrading from windows NT 4.0 to XP. Their job is to know exactly what to do when a client comes to them, and their "knowledge" is hard-won by experience. It will take a few years for such people to retrain to the same level of expertise on linux. It's deeply different. For a large shop:
That, as far as I can gather, is Munich's plan. It is an exceedingly rational one. The main point is that the first two or three years are going to be more expensive. You're going to be paying all the MS taxes and adding massive training costs for techs, and parallel deployments of linux boxes. It's got to be more expensive at first.
You have to appreciate the complete mind warp we are asking windows people to do. After the admin's are onside (this is the really tough part.) They need to get comfortable (they've done some implementations, they don't look for D: anymore to install stuff from. They google for help, and don't think the only source of true knowledge is a vendor) And finally, they have to get attuned (When we need a new application, their first reaction is to check out sf.net & freshmeat, and spend some time evaluating open source before looking at commercial stuff.)
This is seriously relearning how to think kind of stuff. It will take a few years to adjust to. Rolling out desktops has to be the last bit on the end, once all the techies are comfortable and attuned. Because when a client comes to them, they are the expert. The techies will feel really uncomfortable if they are not comfortable.
So like the realistic plan is something like... training for a year, with some pilots, then another year doing some server stuff. That second year will drag into two. Third year you start handle the tougher apps (those without ready analogues), move the clients over to open office, and train the front-line user desk staff. (roll out desktops for the techies.) year four, you do the desktop rollout. I seriously believe that end users in large shops will not require much training at all. All the complications in linux arise from administration tasks: installing software, configuring services, network connections, driver support. All of this stuff is handled by techis in a big shop. So all that is left to users is navigating in the file browser, which, honestly, is not going the take much training.
So in year five, most of your licensing costs drop to 0. Remote administration, for managing applications, configuration, and patches become much easier and simpler (cron + apt-get for debian stable users.), and viruses are something others worry about. So the ratio of admins to users will be able to increase, and you can re-task admins for other fun stuff.
boring stuff...
Air Canada claims that "espionage on a massive scale" took place at the home of WestJet vice president Mark Hill. It wants to search WestJet's records for evidence that WestJet used information from an Air Canada employee-only website to plan its flight schedule and expansion.
In court documents, Hill has admitted that he did access the Air Canada employee-only website using the password and PIN of a former Air Canada employee now working for WestJet. Air Canada claims WestJet logged onto the website thousands of times between May 15, 2003 and March 19, 2004.
The site provides all of Air Canada's ticket sale information.
WestJet says "the information on the website was never used by WestJet in any way related to its business decisions." But Air Canada alleges WestJet used the information to change its routes and improve its expansion plans to better compete with Canada's largest airline.
makes sense to me ;-)
Thought experiment: Order 10000 PC's. time how long it takes to get them installed, with power, network cabling, and cooling, in racks, and installed with the same OS.
Second thought experiment. Imagine the systems are built out of modular bricks that are identical to deskside servers. so that they can sell exactly the same hardware in anywhere from 2 to 512 processors by just plugging the same standard bricks together, and they all get the same shared memory, and run one OS. Rack after rack after rack. That is SGI's architecture. It is absolutely gorgeous.
So they install twenty of the biggest boxes they have, and network those together.
$/buck ? I dunno. Is shared memory really a good idea? Probably not. but it is absolutely gorgeous, and no-one can touch them in that shared memory niche that they have.
uhm... Well 2560 motherboards, 'cause their quad-cpu... Altix is the SGI C-bricks that used were built to house 4 IA64 cpu's per brick. otoh... no... really it really is 20 machines with 512 processors each, because the memory is globally shared (all processors have access to all the memory, albeit at different latency and performance: NUMA (Non Uniform Memory Access). and a single linux kernel is running on the whole thing.
If the dash board includes all the mirrors (multi-function screens), then the driver has to look in a lot fewer directions. Put the car in reverse and the three in dash screens show: left, middle and right rear views. All the views can be seen at once, rather than having to crane the head in different directions to see them all. Many older people especially have difficulty with the mobility required to safely back up a vehicle.
If you are looking in your rear view mirror in order to pass, or because or an interesting event is occurring there (event left as an excercise to the reader
The dash in the Toyota Echo was moved to the centreline in order to reduce the distance the eyes have to move to view the instruments. You can put the mirror displays wherever makes the most sense. Could even be in a HUD on the windshield, or There might be a whole new meaning to driving glasses, with important information projected on the screen there, regardless of where you are looking.
As for the parts being expensive, Electronics used to be expensive, but they are, naturally, very, very cheap. They will get far cheaper as volume increases, and you'll be able to get your cameras at the local NAPA shop. Most of the sensors have perfectly reasonable value in terms of engine control, and should be dirt cheap in volume. Mechanical systems that are expensive and far more custom. Most sensors are relatively cheap already, are solid state, and pretty durable. Compare Dual Holley carbs vs. fuel injectors with electronic sensors, and figure out which stays tuned longer, which gets better mileage (performs better air-gas mixture regulation), and which has lower total cost (once the maintenance is included in the mix.) I think you can add a truckload of sensors for the amount of labour you save.
Cars should include redundant sensors that vote, just like on more expensive vehicles, so that when one sensor fails, the system diagnoses it, and one can get it replaced at leisure without having the car misfire in the meantime.
Cars are going to get simple the way PC hardware is getting trivial. It is cheaper to throw out boards than to troubleshoot them in the PC world. Diagnosing a car should be a matter of understanding what fourty or fifty sensors are saying. Computers are probably better at that than humans, and will be able to give us reasonable diagnoses. Older cars with more primitive computers tend to give garbage diagnoses (not enough data...)
P.S. Silicon is cheap and light.
used to be true for sure. at 3.6, if you want to run "testing/sarge", it's pretty easy now. I installed one a few weeks ago, and apt-get against the debian repositories "just works."
I even tried swapping repositories back and forth and it never got confused.
The one thing that is messy is the kernel. The knoppix kernel documentation is just wrong. It says it is a straight debian kernel, but there are many fiddly bits added (ie. ipw2100 wlan, wavelan, & winmodem drivers, etc...) but the rest is pretty straight forward.
boot knoppix up, under the penguin menu, select Network/Internet-> /dev/modem setup, then there are checkboxes, one of which is for "unsupported winmodem".
YMMV.
It's been a while for me (5 years ago, last time I was in SASH, for the IRIX aware), but all the UNIX recovery tools I saw
booted you into a shell. Knoppix is as if it booted straight into the equivalent of CDE (KDE) and puts an icon of each of your partitions on the screen, that you can just click on to mount and navigate in GUI fashion. Sure, you still need to understand chroot to be able to fix things properly, but it is a heck of a lot easier to use than the older methods. You can check for doc on the internet with a browser (you can GOOGLE!), repartition with a GUI tool.
A problem you don't have with UNIX (because the supported hardware variety is tiny) that is really a killer on PC's is hardware detection. Typically, if you are running a distribution that is a little older, you won't be able to detect some stuff, and you did some magic to get it working. Keeping your rescue disks uptodate with your magic is far more hassle than just downloading the latest knopppix every six months.
Assuming the VA, as a big hospital provider in the US, would use them... that would make "good" RFID tags really attractive. so if an American goes south, rather than just taking his wallet, they'll want to stab the person to dig up the tag. It is small, so it will take a while to find.
keep that thought. I want live in finland and want to phone my Aunt in Australia. What are the chances that they use the same ISP? you want QoS? What are the chances that whatever your ISP does will make the slightest difference once it leaves the realm? Oh.. the ISP's will need to co-operate and all be nice enough to treat eachother's QoS traffic with the respect it needs. OK, what's their cut? oh, you need to bill by the bit, oh, by the kilometer too, oh... welcome to the phone company's world. forget free calls, forget the "because it's cheap" argument because it won't be. Got that?
Now let's be Vonage. Forget QoS, don't bother talking to any ISP's. You get to market quicker, have far wider "coverage" (don't care who the ISP is), can charge less than half what the other guy does, and still make a killing.
The point is not the last mile. Many times downloads proceed at 6 kB/s when the link and the server at the other end are both capable of far more. In that situation, there is a choke point somewhere on the net. Your download bandwidth will be limited by the chokepoint. If you get more priority at the chokepoint, you get faster downloads. In the extreme case of your ISP being badly provisioned, the idea is to get a greater share of the T1.
... oh... an encrypted compressed movie being shared.
The article also held out the hope that this is the tip of the iceberg. Imagine videoconferencing in HD with stereo sound, half a dozen end-points. now 6-20 mb/s of bandwidth is about right. that is a reasonably attractive amount of bandwidth for a downloader. given multi-point connections, and a conference lasting a few hours, how is this different from a bit-torrent session?
Priority is priority. It will be abused. plain human nature. Now folks will say "but we won't let people do that" ! How? This will become a new hack. You've got NAT'ing firewalls at both ends, and arbitrary software (oh, you want to lock down MY computer?! ) hopefully, these streams will be encrypted, so how in your preferred deity's name will you be able to differentiate encrypted compressed multi-media conference from
This is way too hard a problem. It will never be cheap, the folks, like Vonage, that don't bother with it, will be far cheaper and kill anyone who tries to do QoS. Consumers will just learn that that is the way it is, and most of the time, it will be great, but the reliability will not be the same. tough. It's a converged network, that is what it means.
how does one "reduce latency"... hmm... I would think that that would cause the entire network to forward packets faster, more consistently for that traffic. So.. if there is no network congestion, then don't tag the packets, they'll only slow down. If there are bottlenecks, who is going to get a better transfer rate, with or without the QoS flags?