The only correct option here is "all of the above".
Fortnite is definitely more appealing to the addictive personality than the stuff that was around when I was a kid (Doom 1, I'm old). It's the whole "forage, build, fight " that allows pretty useless players to spend some considerable time in the game rather than get nailed in the first 10 seconds.
Parenting (1) - there are a LOT of parents out there who don't pay any attention to their children. Quiet child = good child = child playing Fortnite with headphones on.
Parenting (2) - parents don't know how to say no. If my kids aren't at the dinner table on time, I knock the playstation off the wi-fi. I don't bloody care if you're in the middle of a ranked match, we're having dinner. By the way - Unifi SDN is bloody brilliant for being able to control devices. The eldest got round my WiFi blocking by using an RJ45 connection - not knowing that I could block switch ports as well...
And yes, its a temporary thing. My two have moved onto Apex, certainly in this part of the UK, the Fortnite world is shinking. Most kids don't have a problem with it - they played Fortnite, but were entirely capable of putting it down. Like alcohol, drugs and gambling, there is always a section of society that can't handle it.
My experience is that on the operations space, they are being slaughtered by modern DevOps practices.
A decade ago I was in despair working on live systems with a bunch of offshore people manually hammering in random updates. I literally had a team standing behind the Indian guys telling them to follow the script on updates. We tried to persuade the client to automate it, but they rather liked the idea of hordes of £10 a day people cocking it up.
These days, DevOps is easy - the tools are all there (we used to have to write our own...), and you can have a small team of high-value people managing all environments, perfectly. So replace 100 offshore, with 5 skilled onshore, and get materially better results.
DevOps does not fit the approach of "grab some untrained people and get them on the job" - these are sharp tools, and the inexperienced will slice their hands off.
Satnav has made that knowledge utterly irrelevant. I'm sitting in an uber right now - no idea if the driver knows where he is going, but he can follow instructions.
My journey will cost about £13 in an uber rather than £25 in a cab. Nicer car, too.
i don't think there is an argument that a cab driver should speak the language of the country they are working in, and as a heavy user of Uber in London, I've never had a driver who was unable to speak to me.
If you look up the tests, you'll find that they are heavy on written English - complex comprehensions, writing short essays. I don't see why that is remotely necessary for a cab driver.
It has far more to do with the traditional cabs attempting to secure their market.
Aside from all the issues posted already, the big issue for me is that the in car GPS is stuck in the car. The sort of times when I really need navigation assistance is when I am working in an unfamiliar location. Moving between client sites for example - I can be in the office, ask someone where the next meeting is, and get it into Waze there and then. One a number of occasions I've said to someone "is this it?" and showed them the screen only for them to point out that I have entered the site on the wrong side of town. If I was doing this in the car (on my own), I'd end up at the wrong place.
At the other end (and I accept that is is probably more of a European problem than a US one), it is pretty common to be parking some distance from where you actually want to be. With the phone, this is no problem, I walk with it, and my robot overlord tells me to "turn left at the end of the road". In car GPS - not so good.
I also end up driving multiple cars - hire cars, my own car, my wife's car - I don't have the time or the enthusiasm to learn how to drive the complex & infuriating in car Nav systems, the phone does it fine.
Back when I was using a PII-450 as a file server, I tried out software RAID on 3 x 80 Gb IDE disks. It mostly worked fine - except when it didn't. Generally problems happened when the box was under heavy load - one of the disks would be marked bad, and a painful rebuild would ensue. Once two disks were marked bad - I follwed the terrifying instructions in the "RAID How-To", and got all my data back. That was the last straw for me...I decided that I didn't have time to watch rebuilds all night. Note that this may have been caused by my crummy Promise TX-100 cards, I never bothered to investigate.
I got an Adaptec 2400 IDE controller, and it hasn't blinked for two years. One drive failure, and the swap in worked fine.
If the data is important to you - go hardware. If you want to lean something, and have the time to play, then sofware is OK. Just run frequent backups! If the data is really important to you, buy two identical controllers, and keep one in the box for when the other craps out. Having a perfect raidset, with no controller to read them, would be annoying.
The article may be right about call centre jobs; there are some applications where machines do as good a job as people - though this is not true in customer service applications. A good example is the app British Airways uses for flight information - you tell it the destination and approximate time, and it tells you whether the flight is on time - and it works incredibly well. However, this is not a "customer service" application - if you are phoning up with a complex problem, no computer on earth will be able to help you.
From the perspective of the IT worker, I think that the impact on them will only be beneficial - if intelligent machines can be made to work, then they will be based on intelligent software, which someone has to write/maintain.
As an aside, I remember seeing a presentation from Oracle in about 1994-5 about clever automated database tuning technology, and that all those expensive DBAs would be a thing of the past. When I was at work last week, they were all still there, working damn hard too...
We replaced a horrible mix of Win95 and Win98 with Win2K in 2001. There is still a bit of Win95 around, but it is dying slowly.
We are looking at Longhorn coming out in 2006 (maybe) or 2007 (probably) or 2008 (possibly). If Longhorn comes out in 2007/8 - we would not even consider upgrading until 2009. If there is no driver to change, then we would push further; Longhorn will mean new PCs, which jacks up the cost again. I could easily see a scenario where we are happily running Win2K in 2010. We might be getting a bit itchy by 2014...!
99% of our users need email, simple office and a browser. If Win2K does the job (and it pretty much does)...then what is the incentive to drop $20 million on new PCs and a new OS roll-out? And yes, some form of Linux desktop in about 2007 looks pretty attractive to me...
Maybe I'm going out on a limb here, but I view wireless (802.11 any) as a temporary technology in public spaces. A few problems:
1) There is no roaming built in. When I leave Starbucks and go to another AP, then I have to make a new connection. Compare this to mobile phones which switch base stations automatically
2) It's flakey. I come across about 1 AP in 10 that refuses to play with my card. This isn't good enough for a "consumer" technology
3) The business model doesn't stack up. Running a secure AP costs money - and you'd be surprised at how small existing corporate net connections are at retail outlets
4) The billing is all broken. Can you imagine submitting an expense claim for loads of different wirless outlets? Too hard.
Like Ewan, I have a GPRS card. Mine is Vodafone (UK). I generally connect at 36 Kbps, which is enough for email. With corporate discounts, I have never paid more than GBP 15 a month, and I am a pretty heavy user.
GPRS is nothing compared to 3G, and 3G coverage is starting to become decent in the UK. 3G can hit 2 Mbit under ideal conditions - but 512K is more usual. It will take a year or two to iron out the technical kinks in 3G - but by, say 2005/6 the UK will have ubiquitous coverage. When this is in place, wireless hotspots will be viewed as interesting museum pieces. (No idea what the 3G equivalent is in the States, so YMMV).
Note - my rant (!) is only about public WiFi. WiFi is great in the office - but that is as far as it goes...
Yes. I am evaluating JDS for 8000 seats at a UK organsation. All these comments are relevant for Beta 9, which I am runnning. Beta 10 apparently sucked, and we are awaiting Beta 11/12.
1) It is based on Suse 8.0 - it is a straightforward Linux distribution with some integration work done. If you have used Ximian Desktop (XD2), you will feel right at home.
2) The Java bit is largely marketing. They are focusing on cross platform compatability (Solaris + Linux), so presumably a fair amount of Java is used - but I have not delved into the guts of it.
3) Being Suse 8 based, it is a bit behind the curve in terms of hardware support. My soundcard barfs, the nVidia driver install was interesting. None of this is really relevant for the corporate style desktop we are evaluating. Forget using any weird peripherals at the moment
4) Does it work? A cautious yes so far. Star Office is so nearly there - about 90% of documents are fine - but 10% get really messed up converting.doc ->.sxw. This is not good enough for a mixed Windows/JDS environment. Currently they are using the Ximian Outlook client, which is also good.
5) Java does not have to be slow. Apparent their "Looking Glass" GUI is Java front to back - and when it works, it is pretty cool. McNealy demoed it at the Sun Network conference in Berlin last week. Still many bugs in this though.
6) If this suceeds, this will be the best thing for Linux...ever. They have had a few real wins in the UK - contracts signed, not "evaluation". Some are for 1000 seats +. If this momentum carries on (remember, this product has not been released formally yet), then there will be 1000s of corporate desktops running OpenOffice and Linux apps. Hardware support will improve, and the onus will be on Microsoft to demonstrate value.
7) I'm not sure that Sun quite realise what they are getting into in terms of support. Their standard answer for EOL is "2 product iterations + 5 years". That would make this desktop supportable until 2010. From a corporate viewpoint this is very appealing, but I don't see how they can economically deliver this. I don't get this Wal-Mart deal - this is not aimed at consumers.
8) Their long term plan is to get orgainsations using this - and then move them to SunRays or equivalent. Same desktop, same environment, no issues with changing. SunRays are deeply cool - I would love to be deploying these. No more PCs to patch....
You hit the nail on the head with "corporate users" - and I think this is where they are really aiming.
Our current position at work is:
- 10,000 desktops at a large number of locations, all running Win 2K + Office. They are a pain to admin, and cause havoc by needing 100 Mb service packs to be delivered across our very thin WAN.
- 7,000 of those desktops could be converted to Linux + Openoffice with no loss of productivity. We've done the analysis (they write simple letters, look at simple spreadsheets and go corporate websites that work with Mozilla)
- The remaining 3000 will be harder, but I guess that 2500 of them will convert with some pain - e.g. running Citrix servers to deliver applications that currently rely on ActiveX
- There will be 500 users left over who really use Office. There are lots of them in Fianance - 20 Mb spreadsheets with thousands of lines of code. Absolutley impossible on Open Office at the moment.
So our maths turns out like this:
7000 x $80 For Sun Java Desktop + Openoffice 2500 x $80 + a bunch of pain setting up Citrix sever farms 500 x Office licences + Crossover licences
If you view Crossover as a bridge, rather than a platform, it starts to make sense. At this scale, it will be worth running to get rid of the Win2K build fun and games.
We are trialling Sun JDS at the moment (it doesn't have all of the flashy toys, but it will be supported for 7 years, and it works), and Crossover. So far so good. We aim to have a viable (and formally piloted) strategy by the time our enterprise licence negotiations come up in 2005.
Currently I am working with a lot of Sun kit - and their sales guys. They are absolutely thrilled with Red Hat's new pricing, becuase suddenly they are competitive again.
Consider - a small Oracle DB on a 2 processor machine. The cost of a decent 2 processor server is about $2000, and then the cost of RHAS is about $2700 as I recall. Suddenly the cost of a V240r doesn't seem that bad. We pick them up for a lot less than $4700. Of course we have a pretty good deal with Sun, and the poster may get a good deal with Redhat, but we've done the analysis, and RH does not stack up for us in this example. For me, in is interesting that we have said "no Linux", not because it is a "hacker OS" or it can't do the job - but because it is too expensive to deploy. And before anyone asks, we didn't do any TCO voodoo to prove the point!
Other things Sun have on their side:
- Scalability on the same architecture. Yep, I know 2.6 will scale, but it isn't even properly released yet. We develop on small machines (240s, 480s) and deploy on 15Ks without even thinking about it - apart from making sure that the app can use the CPUs - Solaris - damn good OS, excellent support and an understanding of what enterprise computing is about - Support. Judging by some of the comments here Redhat support is somewhat lacking. Having called regularly on Sun support, I can say it is quite exceptional - even when problems are not their fault, they will engage with other vendors to get a fix
So how does the batch processing that runs against most databases work out the bogus records? You'd need a "bogus" flag or an exclude file. This is the kind of stuff that has systems pumping out thousands of letters to "John F. Kennedy" reminding him that his payment is overdue... Once this mechanism is embedded in the system design, then it will become widely known, and everyone including the janitor's dog will know that they will get fired if they look that the JFK record.
As an academic exercise, great. In the real world..no thanks. However the principle of slightly altering documents to catch the unwary is an old one - the person thinks the document is a copy, whereas it is really unique to them - they publish on f**kedcompany - and they get busted.
I used to think the way you do - but now I think 3G will be different. A lot of these 3G contracts have no monthly charge, and no contract - you pay for the data. The device costs about £200.
So what?
1) I agree that photo/video messaging is pointless, and people won't buy it.
2) How much is a 2Mbit "always on" PCMCIA card worth in your laptop? Granted, the costs at the moment per Gb are pretty ugly - but they won't be for long.
3) How about any device where security and resilience are not paramount, and data throughput is not too high? Think embedded sensors, because the 3G chipsets will be given away before long. Vehicle tracking for example?
4) What about the areas of the world that cannot get broadband? (pretty much anywhere that is > 3 miles from a phone exchange). Satellite broadband is an option in the UK - 3 G is already as cheap as this for light use.
If you think outside the "mobile phone" model, the possibilities are limitless once there is sufficient volume to get the price down.
Sun does not really compete at the low end. A 280R at 17,000 GBP (discount yadda yadda) is not really competitive with a Xeon whatever, but that's not the point. It is binary/OS/Firmware compatible with the F15K/6.8K that I will deploy on, and that's why I will specifiy if for a dev box every time.
Granted an x86 box will blow a 480/3800/280/240 into the weeds (probably) - but an x86 does not deliver the power of 72 CPUs on a 15K - or even 24 on a 6800. This is not about the back end - deploying a stateless web farm on x86 is cheap and good - but the back end DB/App server needs power (>24 CPU) and resilience (zero transaction loss fail over), and x86 does not offer the power at this stage.
There have been a number of suicide attempts where they have tried to use the exhaust from a modern catalysed car...and have failed. Modern engine management reduces the CO and HCs to very low limits indeed. (Modern as in proper closed loop rather than fuel injection + catalyst).
If you count CO2 as pollution (and I do), then you're right - but in terms of the stuff that kills you fast, a modern car is pretty clean.
I think that if you start your Open Source crusade with something hard, then you are doomed to a painful failure.
Scenario A:
You: "I've decided to replace our Oracle financials back-end with MySQL" PHBs: "erm...has anyone else done that? Will it work?" You: "Well, someone runs a big web-site using it...er..." PHBs: "you're fired"
Even if you do persuade them that it is a good idea, replacing the typical 20+ CPU Oracle HR/Financials database with MySQL just ain't going to fly without a hideously expensive conversion project, and even then you will have a mass of functional and scalability issues.
Scenario B:
You: "We could provide some back end sevices using free Open Source software. This new project (web site/file server/test domain needing DHCP etc) is a good test bed for trying this out" PHBs: "erm...has anyone else done it?" You: "Yes, and it will save us a shed load of cash" (produce vast list of Apache/Samba reference sites) PHBs: "I've had a great idea...let's use Open Source..."
Seriously, whatever you do needs to be simple and containable. It also shouldn't be in the front line in the first instance. Once they are happy that it works, and that other people know how to fix it, then you can go further.
High end Unix scales just fine in my experience. If you have seen 10 & 15K partitioned into a number of domains, then they are being used for server consolidation - getting rid of several 6Ks, 4500s etc. The huge advantage is that you can keep 2 CPU boards in reserve and allocate when needed as applications grow.
We are currently performance testing 24 CPU configs and with the intention to scale to 60 when we get the kit. 4 -> 24 has been linear improvement so far.
I agree with the sentiment. 8 and 16 way motherboards/backplanes would be made properly, as opposed to the consumer grade items that Linux currently runs on. Linux would finally have a chance at running a big Oracle DB on decent hardware. This can only be a good thing in terms of good publicity.
CMM is Capability Maturity Model. The scale goes from 1 - 5. It's focus is on repeatability of process. So:
CMM Level 1 - the project is fairly shambolic, but you have version control and the basics are in place.
CMM Level 2 - you have tight version control, defects are linked to item changes, all docs are under version control.
CMM Level 3 - as per 2, but your process is the same on several projects - this is "repeatibility". The advantage is that good management is becoming a process, rather than just being lucky enough to have a good manager.
CMM 4/5 - Never really researched these, but it seems to be about having such a repeatable process that any project you do could be run by a zombie, and it would all come out OK.
Caveat: This is massively paraphrased. There are loads of books on this subject. Do a Google for more.
Most normal development shops are CMM 2 - 4. Many places that have 5 do it by treating a defect as a project in its own right - so after 2000 defects, you can be damned sure you are repeatable.
Here are a few thoughts - I've done similar things on large projects, so it might be useful.
1) For requirements documents, Word is not a bad choice. You will need narrative, formatting and pictures - becuase the one of the target audiences for this is the sponsor of the project and the business people who are paying for it. They have Word on their desktop, they understand it and they can print from it. (Note: I don't like MS any more than the next person, if you have a company preferred alterntive, then use it). Without nice pictures explaining what is happening, the people who are paying for your project won't understand what is going on - and confused managers are dangerous managers in my experience!
2) The point at which we reduce the requirements document to something unreadable is the creation of the Test Model - linking requirements to test conditions. For this we use a home rolled Oracle DB that we use to populate test scripts via ODBC. The test scripts and model are all Word based. (Sorry:-) ). We may be going to RTF soon becuase they are easier to generate from the Sun boxes we have at the back end.
3) You are asking for a CMM 3/4 type of environment. That implies a very rigorous development approach - in order to do the impact analysis of changing your encryption algorithm, you need the developers and designers to be really thorough. If they are not, then all the tools in the world won't help.
4) If find it strange that you are not starting with version control. From my perspective, knowing that encrypt.c version 21 was changed by developer Fred and went into build 723 which became Release 3 is the most important thing. I have seen many projects fail becuase of a lack of version control, and I have seen projects fail becuse they did not write down the requirements. I have never seen a project fail becuase they did not use the right tool for their requirements.
5) We make sure that bugs fixed in one release get fixed in the next by raising multiple problem requests; one for every phase in flight. That way it doesn't matter if Phase 5 is in design or build - someone has to address the problem request and sign it off.
The idea that just because storage is distributed, then it is secure, is only partially true.
If your data is distributed, and one server gets taken out, then fine, you still have service, and the downed server can be re-synched.
If your data is distributed, and someone updates it, then the update is faithfully replicated - even if it is wrong. I work for a company that has its Lotus Notes address database distributed across > 50 locations. One of these would probably survive World War III. Unfortunately, a few years ago, none of them survived a deletion, followed by automatic replication. Took us down for a day, becuase the tapes were only in 1 location.
Of course, you could skip the replication. The you have the non-trivial problem of finding the latest version.
I was on a 4 year project a few years ago. Multiple releases, lots of iterations through the development lifecyle.
We did a test on one of the release developments. It was a bit behind, so putting a few hours in was reasonable. We logged what was achieved in each week, and tracked it through to the end of the release. Our standard week was 8 hour days, no week end work. This was solid programming - no meetings etc - the design arrived on your desk, and you coded it. The experiment went as follows:
Week 1: 14 hour days. Week 2: 14 hour days Week 3: 14 hour days Week 4: 8 hour days
(we had no week-end work in any on these weeks).
OK - the results were:
Productivity Week 1 was 14/8 x normal. Great. Productivity Week 2 was normal. Not great, because we had shelled out for overtime Productivity Week 3 was worse than normal. Very bad - we were making worse progress than before, and we were paying for overtime Productivity Week 4 was = normal. OK, happy with this
The main problems during weeks 2 & 3 showed up during later testing phases - basic testing was sloppy, and programmers had followed designs blindly, rather than questioning what they were told to do. However (and this is important) - the build phase was completed quickly during the overtime phase - the resulting code sucked, but no-one knew until later phases.
The moral of the story is that a dedicated team can bust themselves for a week or two. They can probably pull all-nighters, and still deliver good code. Beyond that, productivity sucks, and pushing a team to do this will hurt in the long run. People need to think, and question what they are doing - tired people don't do this.
Just FYI, I was one of the coders in this experiment, and as a PHB now, I use this example whenever I see a plan that assumes 12 hour days from the beginning. 12 hour planned days == 16 hour days in the real world.
Using the classic government approach, "they" are also going to rig the implementation of this. The major routes in London really depend on traffic light phasing - and this has been seriously screwed up in the last few months. As a consequence traffic jams have appeared where none were before. Then "they" will switch on the congestion charge, fix the phasing, and claim that congestion charging is the saviour of London.
Oh well, if it gets the poor in their crappy Mazdas off the road...er...I thought the Mayor was a socialist...
(if anyone doesn't believe this, go check out the City Road/Old Street roundabout. There is a jam there, going towards Angel that is solely caused by the lights. The junction has been physically the same for all of the 30 years I have known it - and suddenly the traffic is screwed. Wonder why...oh yes, this is the boundary of the congestion charge zone)
If you can convince the business owner that there is a benefit in open-souring the application, then they will go for it. Do you mean true open source (everyone gets the code), or shared IPR - in which the business owner gets the code, so at least they can hire someone in the future to update it?
I'd guess the arguments for true open source would be:
1) That the software doesn't form a part of their competitive advantage. If their key selling point is that their service is better - and because of this software, they CAN make their service better, then they'd be mad to give it away. If it is only used to satisfy some pain in the ass regulation, then they might consider it.
2) The advantage of opensourcing (if you get through (1)) is that other people might contribute to bugfixing and maintenance - this will reduce their costs in the longer term. However, running an open source project demands time - which will increase costs. If there is likely to be some form of community spirit, then there is more chance of this happening - i.e. there are lots of businesses with the same problem.
3) Open source is better than closed source. They won't care about this, as they will have the source already if they've written your contract correctly.:-)
Slashdot Mirror
The only correct option here is "all of the above".
Fortnite is definitely more appealing to the addictive personality than the stuff that was around when I was a kid (Doom 1, I'm old). It's the whole "forage, build, fight " that allows pretty useless players to spend some considerable time in the game rather than get nailed in the first 10 seconds.
Parenting (1) - there are a LOT of parents out there who don't pay any attention to their children. Quiet child = good child = child playing Fortnite with headphones on.
Parenting (2) - parents don't know how to say no. If my kids aren't at the dinner table on time, I knock the playstation off the wi-fi. I don't bloody care if you're in the middle of a ranked match, we're having dinner. By the way - Unifi SDN is bloody brilliant for being able to control devices. The eldest got round my WiFi blocking by using an RJ45 connection - not knowing that I could block switch ports as well...
And yes, its a temporary thing. My two have moved onto Apex, certainly in this part of the UK, the Fortnite world is shinking. Most kids don't have a problem with it - they played Fortnite, but were entirely capable of putting it down. Like alcohol, drugs and gambling, there is always a section of society that can't handle it.
My experience is that on the operations space, they are being slaughtered by modern DevOps practices.
A decade ago I was in despair working on live systems with a bunch of offshore people manually hammering in random updates. I literally had a team standing behind the Indian guys telling them to follow the script on updates. We tried to persuade the client to automate it, but they rather liked the idea of hordes of £10 a day people cocking it up.
These days, DevOps is easy - the tools are all there (we used to have to write our own...), and you can have a small team of high-value people managing all environments, perfectly. So replace 100 offshore, with 5 skilled onshore, and get materially better results.
DevOps does not fit the approach of "grab some untrained people and get them on the job" - these are sharp tools, and the inexperienced will slice their hands off.
Satnav has made that knowledge utterly irrelevant. I'm sitting in an uber right now - no idea if the driver knows where he is going, but he can follow instructions.
My journey will cost about £13 in an uber rather than £25 in a cab. Nicer car, too.
i don't think there is an argument that a cab driver should speak the language of the country they are working in, and as a heavy user of Uber in London, I've never had a driver who was unable to speak to me.
If you look up the tests, you'll find that they are heavy on written English - complex comprehensions, writing short essays. I don't see why that is remotely necessary for a cab driver.
It has far more to do with the traditional cabs attempting to secure their market.
Aside from all the issues posted already, the big issue for me is that the in car GPS is stuck in the car. The sort of times when I really need navigation assistance is when I am working in an unfamiliar location. Moving between client sites for example - I can be in the office, ask someone where the next meeting is, and get it into Waze there and then. One a number of occasions I've said to someone "is this it?" and showed them the screen only for them to point out that I have entered the site on the wrong side of town. If I was doing this in the car (on my own), I'd end up at the wrong place.
At the other end (and I accept that is is probably more of a European problem than a US one), it is pretty common to be parking some distance from where you actually want to be. With the phone, this is no problem, I walk with it, and my robot overlord tells me to "turn left at the end of the road". In car GPS - not so good.
I also end up driving multiple cars - hire cars, my own car, my wife's car - I don't have the time or the enthusiasm to learn how to drive the complex & infuriating in car Nav systems, the phone does it fine.
I would support the sentiment.
Back when I was using a PII-450 as a file server, I tried out software RAID on 3 x 80 Gb IDE disks. It mostly worked fine - except when it didn't. Generally problems happened when the box was under heavy load - one of the disks would be marked bad, and a painful rebuild would ensue. Once two disks were marked bad - I follwed the terrifying instructions in the "RAID How-To", and got all my data back. That was the last straw for me...I decided that I didn't have time to watch rebuilds all night. Note that this may have been caused by my crummy Promise TX-100 cards, I never bothered to investigate.
I got an Adaptec 2400 IDE controller, and it hasn't blinked for two years. One drive failure, and the swap in worked fine.
If the data is important to you - go hardware. If you want to lean something, and have the time to play, then sofware is OK. Just run frequent backups! If the data is really important to you, buy two identical controllers, and keep one in the box for when the other craps out. Having a perfect raidset, with no controller to read them, would be annoying.
The article may be right about call centre jobs; there are some applications where machines do as good a job as people - though this is not true in customer service applications. A good example is the app British Airways uses for flight information - you tell it the destination and approximate time, and it tells you whether the flight is on time - and it works incredibly well. However, this is not a "customer service" application - if you are phoning up with a complex problem, no computer on earth will be able to help you.
From the perspective of the IT worker, I think that the impact on them will only be beneficial - if intelligent machines can be made to work, then they will be based on intelligent software, which someone has to write/maintain.
As an aside, I remember seeing a presentation from Oracle in about 1994-5 about clever automated database tuning technology, and that all those expensive DBAs would be a thing of the past. When I was at work last week, they were all still there, working damn hard too...
In corporate land, they may well be.
We replaced a horrible mix of Win95 and Win98 with Win2K in 2001. There is still a bit of Win95 around, but it is dying slowly.
We are looking at Longhorn coming out in 2006 (maybe) or 2007 (probably) or 2008 (possibly). If Longhorn comes out in 2007/8 - we would not even consider upgrading until 2009. If there is no driver to change, then we would push further; Longhorn will mean new PCs, which jacks up the cost again. I could easily see a scenario where we are happily running Win2K in 2010. We might be getting a bit itchy by 2014...!
99% of our users need email, simple office and a browser. If Win2K does the job (and it pretty much does)...then what is the incentive to drop $20 million on new PCs and a new OS roll-out? And yes, some form of Linux desktop in about 2007 looks pretty attractive to me...
Maybe I'm going out on a limb here, but I view wireless (802.11 any) as a temporary technology in public spaces. A few problems:
1) There is no roaming built in. When I leave Starbucks and go to another AP, then I have to make a new connection. Compare this to mobile phones which switch base stations automatically
2) It's flakey. I come across about 1 AP in 10 that refuses to play with my card. This isn't good enough for a "consumer" technology
3) The business model doesn't stack up. Running a secure AP costs money - and you'd be surprised at how small existing corporate net connections are at retail outlets
4) The billing is all broken. Can you imagine submitting an expense claim for loads of different wirless outlets? Too hard.
Like Ewan, I have a GPRS card. Mine is Vodafone (UK). I generally connect at 36 Kbps, which is enough for email. With corporate discounts, I have never paid more than GBP 15 a month, and I am a pretty heavy user.
GPRS is nothing compared to 3G, and 3G coverage is starting to become decent in the UK. 3G can hit 2 Mbit under ideal conditions - but 512K is more usual. It will take a year or two to iron out the technical kinks in 3G - but by, say 2005/6 the UK will have ubiquitous coverage. When this is in place, wireless hotspots will be viewed as interesting museum pieces. (No idea what the 3G equivalent is in the States, so YMMV).
Note - my rant (!) is only about public WiFi. WiFi is great in the office - but that is as far as it goes...
Yes. I am evaluating JDS for 8000 seats at a UK organsation. All these comments are relevant for Beta 9, which I am runnning. Beta 10 apparently sucked, and we are awaiting Beta 11/12.
.doc -> .sxw. This is not good enough for a mixed Windows/JDS environment. Currently they are using the Ximian Outlook client, which is also good.
1) It is based on Suse 8.0 - it is a straightforward Linux distribution with some integration work done. If you have used Ximian Desktop (XD2), you will feel right at home.
2) The Java bit is largely marketing. They are focusing on cross platform compatability (Solaris + Linux), so presumably a fair amount of Java is used - but I have not delved into the guts of it.
3) Being Suse 8 based, it is a bit behind the curve in terms of hardware support. My soundcard barfs, the nVidia driver install was interesting. None of this is really relevant for the corporate style desktop we are evaluating. Forget using any weird peripherals at the moment
4) Does it work? A cautious yes so far. Star Office is so nearly there - about 90% of documents are fine - but 10% get really messed up converting
5) Java does not have to be slow. Apparent their "Looking Glass" GUI is Java front to back - and when it works, it is pretty cool. McNealy demoed it at the Sun Network conference in Berlin last week. Still many bugs in this though.
6) If this suceeds, this will be the best thing for Linux...ever. They have had a few real wins in the UK - contracts signed, not "evaluation". Some are for 1000 seats +. If this momentum carries on (remember, this product has not been released formally yet), then there will be 1000s of corporate desktops running OpenOffice and Linux apps. Hardware support will improve, and the onus will be on Microsoft to demonstrate value.
7) I'm not sure that Sun quite realise what they are getting into in terms of support. Their standard answer for EOL is "2 product iterations + 5 years". That would make this desktop supportable until 2010. From a corporate viewpoint this is very appealing, but I don't see how they can economically deliver this. I don't get this Wal-Mart deal - this is not aimed at consumers.
8) Their long term plan is to get orgainsations using this - and then move them to SunRays or equivalent. Same desktop, same environment, no issues with changing. SunRays are deeply cool - I would love to be deploying these. No more PCs to patch....
You hit the nail on the head with "corporate users" - and I think this is where they are really aiming.
Our current position at work is:
- 10,000 desktops at a large number of locations, all running Win 2K + Office. They are a pain to admin, and cause havoc by needing 100 Mb service packs to be delivered across our very thin WAN.
- 7,000 of those desktops could be converted to Linux + Openoffice with no loss of productivity. We've done the analysis (they write simple letters, look at simple spreadsheets and go corporate websites that work with Mozilla)
- The remaining 3000 will be harder, but I guess that 2500 of them will convert with some pain - e.g. running Citrix servers to deliver applications that currently rely on ActiveX
- There will be 500 users left over who really use Office. There are lots of them in Fianance - 20 Mb spreadsheets with thousands of lines of code. Absolutley impossible on Open Office at the moment.
So our maths turns out like this:
7000 x $80 For Sun Java Desktop + Openoffice
2500 x $80 + a bunch of pain setting up Citrix sever farms
500 x Office licences + Crossover licences
If you view Crossover as a bridge, rather than a platform, it starts to make sense. At this scale, it will be worth running to get rid of the Win2K build fun and games.
We are trialling Sun JDS at the moment (it doesn't have all of the flashy toys, but it will be supported for 7 years, and it works), and Crossover. So far so good. We aim to have a viable (and formally piloted) strategy by the time our enterprise licence negotiations come up in 2005.
Currently I am working with a lot of Sun kit - and their sales guys. They are absolutely thrilled with Red Hat's new pricing, becuase suddenly they are competitive again.
Consider - a small Oracle DB on a 2 processor machine. The cost of a decent 2 processor server is about $2000, and then the cost of RHAS is about $2700 as I recall. Suddenly the cost of a V240r doesn't seem that bad. We pick them up for a lot less than $4700. Of course we have a pretty good deal with Sun, and the poster may get a good deal with Redhat, but we've done the analysis, and RH does not stack up for us in this example. For me, in is interesting that we have said "no Linux", not because it is a "hacker OS" or it can't do the job - but because it is too expensive to deploy. And before anyone asks, we didn't do any TCO voodoo to prove the point!
Other things Sun have on their side:
- Scalability on the same architecture. Yep, I know 2.6 will scale, but it isn't even properly released yet. We develop on small machines (240s, 480s) and deploy on 15Ks without even thinking about it - apart from making sure that the app can use the CPUs
- Solaris - damn good OS, excellent support and an understanding of what enterprise computing is about
- Support. Judging by some of the comments here Redhat support is somewhat lacking. Having called regularly on Sun support, I can say it is quite exceptional - even when problems are not their fault, they will engage with other vendors to get a fix
So how does the batch processing that runs against most databases work out the bogus records? You'd need a "bogus" flag or an exclude file. This is the kind of stuff that has systems pumping out thousands of letters to "John F. Kennedy" reminding him that his payment is overdue... Once this mechanism is embedded in the system design, then it will become widely known, and everyone including the janitor's dog will know that they will get fired if they look that the JFK record.
As an academic exercise, great. In the real world..no thanks. However the principle of slightly altering documents to catch the unwary is an old one - the person thinks the document is a copy, whereas it is really unique to them - they publish on f**kedcompany - and they get busted.
I used to think the way you do - but now I think 3G will be different. A lot of these 3G contracts have no monthly charge, and no contract - you pay for the data. The device costs about £200.
So what?
1) I agree that photo/video messaging is pointless, and people won't buy it.
2) How much is a 2Mbit "always on" PCMCIA card worth in your laptop? Granted, the costs at the moment per Gb are pretty ugly - but they won't be for long.
3) How about any device where security and resilience are not paramount, and data throughput is not too high? Think embedded sensors, because the 3G chipsets will be given away before long. Vehicle tracking for example?
4) What about the areas of the world that cannot get broadband? (pretty much anywhere that is > 3 miles from a phone exchange). Satellite broadband is an option in the UK - 3 G is already as cheap as this for light use.
If you think outside the "mobile phone" model, the possibilities are limitless once there is sufficient volume to get the price down.
Sun does not really compete at the low end. A 280R at 17,000 GBP (discount yadda yadda) is not really competitive with a Xeon whatever, but that's not the point. It is binary/OS/Firmware compatible with the F15K/6.8K that I will deploy on, and that's why I will specifiy if for a dev box every time.
Granted an x86 box will blow a 480/3800/280/240 into the weeds (probably) - but an x86 does not deliver the power of 72 CPUs on a 15K - or even 24 on a 6800. This is not about the back end - deploying a stateless web farm on x86 is cheap and good - but the back end DB/App server needs power (>24 CPU) and resilience (zero transaction loss fail over), and x86 does not offer the power at this stage.
There have been a number of suicide attempts where they have tried to use the exhaust from a modern catalysed car...and have failed. Modern engine management reduces the CO and HCs to very low limits indeed. (Modern as in proper closed loop rather than fuel injection + catalyst).
If you count CO2 as pollution (and I do), then you're right - but in terms of the stuff that kills you fast, a modern car is pretty clean.
I think that if you start your Open Source crusade with something hard, then you are doomed to a painful failure.
Scenario A:
You: "I've decided to replace our Oracle financials back-end with MySQL"
PHBs: "erm...has anyone else done that? Will it work?"
You: "Well, someone runs a big web-site using it...er..."
PHBs: "you're fired"
Even if you do persuade them that it is a good idea, replacing the typical 20+ CPU Oracle HR/Financials database with MySQL just ain't going to fly without a hideously expensive conversion project, and even then you will have a mass of functional and scalability issues.
Scenario B:
You: "We could provide some back end sevices using free Open Source software. This new project (web site/file server/test domain needing DHCP etc) is a good test bed for trying this out"
PHBs: "erm...has anyone else done it?"
You: "Yes, and it will save us a shed load of cash" (produce vast list of Apache/Samba reference sites)
PHBs: "I've had a great idea...let's use Open Source..."
Seriously, whatever you do needs to be simple and containable. It also shouldn't be in the front line in the first instance. Once they are happy that it works, and that other people know how to fix it, then you can go further.
High end Unix scales just fine in my experience. If you have seen 10 & 15K partitioned into a number of domains, then they are being used for server consolidation - getting rid of several 6Ks, 4500s etc. The huge advantage is that you can keep 2 CPU boards in reserve and allocate when needed as applications grow.
We are currently performance testing 24 CPU configs and with the intention to scale to 60 when we get the kit. 4 -> 24 has been linear improvement so far.
I agree with the sentiment. 8 and 16 way motherboards/backplanes would be made properly, as opposed to the consumer grade items that Linux currently runs on. Linux would finally have a chance at running a big Oracle DB on decent hardware. This can only be a good thing in terms of good publicity.
CMM is Capability Maturity Model. The scale goes from 1 - 5. It's focus is on repeatability of process. So:
CMM Level 1 - the project is fairly shambolic, but you have version control and the basics are in place.
CMM Level 2 - you have tight version control, defects are linked to item changes, all docs are under version control.
CMM Level 3 - as per 2, but your process is the same on several projects - this is "repeatibility". The advantage is that good management is becoming a process, rather than just being lucky enough to have a good manager.
CMM 4/5 - Never really researched these, but it seems to be about having such a repeatable process that any project you do could be run by a zombie, and it would all come out OK.
Caveat: This is massively paraphrased. There are loads of books on this subject. Do a Google for more.
Most normal development shops are CMM 2 - 4. Many places that have 5 do it by treating a defect as a project in its own right - so after 2000 defects, you can be damned sure you are repeatable.
Here are a few thoughts - I've done similar things on large projects, so it might be useful.
:-) ). We may be going to RTF soon becuase they are easier to generate from the Sun boxes we have at the back end.
1) For requirements documents, Word is not a bad choice. You will need narrative, formatting and pictures - becuase the one of the target audiences for this is the sponsor of the project and the business people who are paying for it. They have Word on their desktop, they understand it and they can print from it. (Note: I don't like MS any more than the next person, if you have a company preferred alterntive, then use it). Without nice pictures explaining what is happening, the people who are paying for your project won't understand what is going on - and confused managers are dangerous managers in my experience!
2) The point at which we reduce the requirements document to something unreadable is the creation of the Test Model - linking requirements to test conditions. For this we use a home rolled Oracle DB that we use to populate test scripts via ODBC. The test scripts and model are all Word based. (Sorry
3) You are asking for a CMM 3/4 type of environment. That implies a very rigorous development approach - in order to do the impact analysis of changing your encryption algorithm, you need the developers and designers to be really thorough. If they are not, then all the tools in the world won't help.
4) If find it strange that you are not starting with version control. From my perspective, knowing that encrypt.c version 21 was changed by developer Fred and went into build 723 which became Release 3 is the most important thing. I have seen many projects fail becuase of a lack of version control, and I have seen projects fail becuse they did not write down the requirements. I have never seen a project fail becuase they did not use the right tool for their requirements.
5) We make sure that bugs fixed in one release get fixed in the next by raising multiple problem requests; one for every phase in flight. That way it doesn't matter if Phase 5 is in design or build - someone has to address the problem request and sign it off.
The idea that just because storage is distributed, then it is secure, is only partially true.
If your data is distributed, and one server gets taken out, then fine, you still have service, and the downed server can be re-synched.
If your data is distributed, and someone updates it, then the update is faithfully replicated - even if it is wrong. I work for a company that has its Lotus Notes address database distributed across > 50 locations. One of these would probably survive World War III. Unfortunately, a few years ago, none of them survived a deletion, followed by automatic replication. Took us down for a day, becuase the tapes were only in 1 location.
Of course, you could skip the replication. The you have the non-trivial problem of finding the latest version.
I was on a 4 year project a few years ago. Multiple releases, lots of iterations through the development lifecyle.
We did a test on one of the release developments. It was a bit behind, so putting a few hours in was reasonable. We logged what was achieved in each week, and tracked it through to the end of the release. Our standard week was 8 hour days, no week end work. This was solid programming - no meetings etc - the design arrived on your desk, and you coded it. The experiment went as follows:
Week 1: 14 hour days.
Week 2: 14 hour days
Week 3: 14 hour days
Week 4: 8 hour days
(we had no week-end work in any on these weeks).
OK - the results were:
Productivity Week 1 was 14/8 x normal. Great.
Productivity Week 2 was normal. Not great, because we had shelled out for overtime
Productivity Week 3 was worse than normal. Very bad - we were making worse progress than before, and we were paying for overtime
Productivity Week 4 was = normal. OK, happy with this
The main problems during weeks 2 & 3 showed up during later testing phases - basic testing was sloppy, and programmers had followed designs blindly, rather than questioning what they were told to do. However (and this is important) - the build phase was completed quickly during the overtime phase - the resulting code sucked, but no-one knew until later phases.
The moral of the story is that a dedicated team can bust themselves for a week or two. They can probably pull all-nighters, and still deliver good code. Beyond that, productivity sucks, and pushing a team to do this will hurt in the long run. People need to think, and question what they are doing - tired people don't do this.
Just FYI, I was one of the coders in this experiment, and as a PHB now, I use this example whenever I see a plan that assumes 12 hour days from the beginning. 12 hour planned days == 16 hour days in the real world.
Using the classic government approach, "they" are also going to rig the implementation of this. The major routes in London really depend on traffic light phasing - and this has been seriously screwed up in the last few months. As a consequence traffic jams have appeared where none were before. Then "they" will switch on the congestion charge, fix the phasing, and claim that congestion charging is the saviour of London.
Oh well, if it gets the poor in their crappy Mazdas off the road...er...I thought the Mayor was a socialist...
(if anyone doesn't believe this, go check out the City Road/Old Street roundabout. There is a jam there, going towards Angel that is solely caused by the lights. The junction has been physically the same for all of the 30 years I have known it - and suddenly the traffic is screwed. Wonder why...oh yes, this is the boundary of the congestion charge zone)
I have about 40 Gb of ripped MP3s online. I also have every CD that they originate from on the shelf behind me. Why do I do it?
1) Because I can
2) Because I've paid for a bunch of upstream bandwidth that I never use
3) Because I wanted to know that software RAID 5 works, and I needed some files to test with
4) Because I am hacked off with spending money on awful albums that I never listen to
5) Because I can
Unless there is a law (in my juristiction) that says owning MP3s is illegal, then what law am I breaking? Failing to sufficiently protect my computer?
If you can convince the business owner that there is a benefit in open-souring the application, then they will go for it. Do you mean true open source (everyone gets the code), or shared IPR - in which the business owner gets the code, so at least they can hire someone in the future to update it?
:-)
I'd guess the arguments for true open source would be:
1) That the software doesn't form a part of their competitive advantage. If their key selling point is that their service is better - and because of this software, they CAN make their service better, then they'd be mad to give it away. If it is only used to satisfy some pain in the ass regulation, then they might consider it.
2) The advantage of opensourcing (if you get through (1)) is that other people might contribute to bugfixing and maintenance - this will reduce their costs in the longer term. However, running an open source project demands time - which will increase costs. If there is likely to be some form of community spirit, then there is more chance of this happening - i.e. there are lots of businesses with the same problem.
3) Open source is better than closed source. They won't care about this, as they will have the source already if they've written your contract correctly.