First, I must declare an interest: I work for Sendmail Inc. which markets an IMAp/POP3 mail server solution.
What you have to ask them is why they want Exchange/Outlook. If you have a good IMAP implementation, you can use Outlook on the front end and your users will get folders on the server + shared folders and syncing and all that stuff.
If you want calendaring, the Outlook/IMAP solution will give you that on an individual basis. You don't get group calendaring, *but* nobody really uses that. I've worked at four companies, two were Exchange shops, one was a Notes shop and my current one uses a product called Meeting Maker. In none of them did people use the group calendaring seriously and my current company is the only one that uses it at all.
Directory access: get an LDAP server - any LDAP server. OpenLDAP is free, but there are also commercial ones with nice admin tools.
Then there is cost: a client access licence for Exchange is about £500 in the UK. My company has just launched an IMAP server which for a thousand users will cost maybe £5 per user, or you can get an open source one.
If you use products that support open standards such as POP, IMAP, LDAP and SMTP then you will not be tied into any manufacturer's products. On the other hand that manufacturer's products *will* have support for the open standards e.g. buy Exchange - you *must* put Outlook on every PC. Buy any IMAP server - you *can* use Outlook on each PC.
Sendmail.conf requires the bat book, in reality bible.
If the Sendmail conf was in an XML file it would still require a bible. The complexity of sendmail configuration arises from the semantics of what the config does, not its syntax.
Random access: read your text config file into memory on app start-up. If it's too big, there's something wrong with your app - rewrite it... Even sendmail reads its entire config into RAM.
Backup and recovery: Make a copy of your text file. Better still, manage it with your favourite source code control tool, but make a backup anyway incase your changes screw the source code control tool.
Personally I think config files should be edittable with any text editor. You can probably assume a worst case of "vi" although in my early days of working with Unix I did once have to edit a config file with ed because the customer hadn't installed vi and I didn't have time to learn emacs. Of course, being able to change the config with a text editor is no excuse for not having a friendly graphical interface too.
The syntax should be simple and easy to understand for a human techy. That may disqualify XML with all its tags and angle brackets etc. I tend to go for a format similar to the old MS ini format. e.g.
# this is a comment
[section]
keyword=value
Also, separate files for separate programs. The big problem with the M$ registry is that your program is configured in the same database as all of those nasty and yet essential device drivers and so on.
Point 1: I believe the guy who stole the Enigma was going to ransom it back to BP or more accurately, he was going to ransom the three rotors having already sent back the rest of the machine.
Point 2: It's too simplistic to say that Alan Turing broke Enigma. Enigma was first cracked by the Polish who were also responsible for inventing the electro-mechanical device know as the Bombe which was used for key recovery. The Poles handed all the info over to the Brits when the Germans introduced two more rotors (i.e. on army and luftwaffe machines, three rotors were chosen from a set of five each day) because they didn't have the resources to cope with the extra complexity of the machine.
Alan Turing's contribution was more to do with improving the existing methods of breaking enigma and countering the Germans' improvements in Enigma. That's not to belittle him. It has been said that his contribution to winning the war was the most important by any individual (unless you count Hitler's monumental incompetance).
OK I've read the article now. Greenspun's idea that a programmer has to work a 70 hour week is based on the premise that he/she has to spend 25 hours a week just coordinating with the other people in the organisation. I would suggest that it is much better to try and reduce the unproductive 25 hours rather than increase the productive 30 hours - or actually in my case 15 hours (my contract is for a 40 hour week). There are lots of techniques for doing this. The best book I've seen on the subject is Steve MaGuire's "Debugging the Development Process" which I would recommend to any aspiring software project manager.
There are several clues in the text of Greenspun's article e.g. a project meeting requiring five managers to attend (hmmm......) which suggest that his company needs a serious look at the way it runs projects. In fairness, he does allude to the fact that this is going on.
I admit I haven't read the article because it's slashdotted at the moment, but having read a lot of the comments I think I'm on safe ground assuming he advocates a 70 hour week for programmers.
There are several reasons why this is a crazy idea. One is the burn out problem. Assuming they're working a 6 day week, that's just under 12 hours a day. There's no way anybody can stay productive at that rate for any length of time. Actually, to put it in perspective, until recently, newly qualified doctors here in the UK had to spend their first year effectively doing slave labour in our hospitals. 100 hour weeks were not uncommon.
Two is the fact that a programmer is working a 12 hour day, activities that normally do not count as work tend to migrate into it. For example, if you have to go to your bank, you might do it in office hours; because you are working long hours, you'll have frequent breaks to do things like play Quake, surf the net, organise your vacation or go and work out for a bit; if you're working late in the evening it is not unreasonable to have something to eat etc etc. I don't know if anybody has done any scientific research into it, but I bet the 12 hour a day programmer spends about as much time actually producing code as the 8 hour a day programmer.
Reason three, Brookes' law states that putting more resource onto a late project makes it later.
The reason for this is twofold:
a) programming tasks are inherently single threaded - only one person can code one module. If you have already broken out the tasks into the most basic units and assigned resource to each one, adding more programmers will have no effect on the schedule except that
b) new programmers rarely come into a project knowing everything they need to be productive, so you have to take your existing resource off production to train the new ones.
If your project is late, there is one way to beat Brookes' law. You can ask your programmers to work longer hours. If they're already working a 12 hour day, this is probably not an option and for reasons 1 and 2 above probably not effective. However, if they are working an 8 hour day, you could ask them to go to 12 hours for short periods (e.g. a couple of weeks).
Personally I value my leisure time far to much to work for any company that insisted on a 70 hour week. Actually it's illegal in the UK and the rest of the European Union.
You should never consider any e-mail transmitted in clear text to be private. If my doctor was sending such e-mails to me at any place (home or work), I'd take him aside and introduce him to cryptography.
There's lots of stuff in RIP that I disagree with, but frankly, if you are sending stuff across their infrastructure (e- or snail- mail) that you don't want your company to see and you get found out, you deserve to be fired for stupidity.
I thought it would be a fun idea to flame the author, but then I realised lots of other people would be doing it anyway, so it wouldn't be original unless I got first post:-)
They mentioned that other services were having funding problems and for that reason were withdrawing their services
I think they're referring to Line One and others writing to their customers claiming they were spending too much time on line and trying to limit them to 17 hours a week. Apparently they didn't realise that if you have free internet access you will leave it on all the time.
Neither actually, the Commodore 64 and Pet were both produced by a company called.... Commodore. The guy who used to run Commodore (Jack Tramiel) did take over at Atari after he was booted out of Commodore for nearly bankrupting them.
Atari did have some sort of home PC which us Commie owners looked down on with contempt (this was before the ST).
As a Company trading in the UK, Tesco is subject to the Data Protection Act. This means that they have certain obligations wrt any personal data they might collect from you.
As for the particular issue of collecting information about your browser, the DPA says they must discard data as soon as they have finished using it for its legitimate purpose i.e. once the page has been constructed.
As for the fact that the web page only works for two browsers - well that is just bad programming. If I find a page that doesn't work, I always submit a bug report. In software terms, web sites are often very poorly engineered (IMHO) and a little constructive criticism may just possibly improve things a bit.
As it happens, under the usual criteria for judging server OSes (scalability, reliability, security) Linux is not a particulary good server OS - it's just that Windows NT makes it look good.
OTOH, it's cheap and easy to get hold of. There's loads of support available on the Internet and there are lots of applications available which are also cheap or free.
On the desktop, Linux has a big achilles heel in that you don't always have the latest hardware support. Hardware manufacturers put a lot of effort into writing drivers for Windows as 90% of the units they sell will end up in Windows boxes, but with Linux you are reliant on somebody in the Linux community coming up with a driver unless you are a systems programmer.
When I got my new Dell CSx laptop, it came preconfigured to install Windows when I first switched it on. Ok, the process requires four reboots and takes about an hour and a half, but at the end of that the PC and all of its peripherals were functioning perfectly.
Then I came to install RH Linux on the same laptop. The install took about an hour with two reboots (the first one being so I could restart the install in text mode because the RH install usually starts an X-server so that it can look pretty, and the X-server refused to talk to my graphics card). However, at the end of this I had no GUI. XFree86 absolutely refused to do anything with my graphics card as it was too new. I estimate I took about 16 hours or more to get it working. Is the average person going to spend that length of time getting their PC to work? I don't think so. He/she'll format c: and reinstall Windows.
However, in the corporate environment where the IT dept can control both the hardware standards and Linux config, I think it would make an extremely good desktop OS.
That's a story in Douglas Hofstadter's book "Godel Escher Bach, An Eternal Golden Braid". The particular brand of computer and operating system they were talking about was not mentioned.
Proof mechanisms *are* inherently too limited for real world situations. For a start, how do you prove 1/2 a million lines of code (say). It'll take some time, unless you use an automated proving tool. How do you know you can trust the proving tool? You have to prove it. Even if you have 100% proved the source code is OK, what about the compiler / interpreter? What about the operating system, CPU microcode, the logic design of the chip etc etc etc.
At some point you have got to stop and just trust everything below that level. Taking gcc as an example, how do we know it always produces correct code. Has anybody done any formal tests to prove it? No, but I bet it hardly ever occurs to anybody that their problems may be a result of a compiler bug. Enough people use gcc every day without problems to make it fairly trustworthy. Is trust built on experience any less valuable than trust built on formal methods?
That'll be good. Win9x - well the important bits like the kernel and GDI etc etc - is written in Intel x86 assembler. I foresee that it will be a challenge to port it to a Sparc box.
He means -1 is imaginary in the sense that it is a mathematical abstraction to make it easier to answer questions like what is 1 - 2 ? You can't have a set of -1 objects, like you can have a set of 1, 2, 3 or even 0 objects.
He does not mean that -1 is a complex number with a real part of 0. Although he was being deliberately confusing.
I thought rockets came before jet propulsion. There was that Goddard guy and the Chinese of course. I'd go for electricity and quantum mechanics for the 20th and probably genetics for the 21st.
Cobol programmers. The default way of storing numbers in Cobol is effectively as a string. All the code to do conversion is done by the compiler and is transparent to the programmer.
Does having a clue about quality include reviewing your output to determine whether, for instance, you have accidentally substituted a "w" for an "f" in the word "filled"?
I can't think of one non trivial piece of software that I use today that was created by a "rogue programmer in the basement". It's all simply too big and complex for one person to write on their own. Even successful Open Source projects follow a methodology (see Eric Raymond's "The Cathedral and the Bazaar").
Good methodologies are designed to protect the project from idiots of all types. These include idiot users, idiot customers, idiot programmers, idiot designers and, most importantly, idiot managers. Some of them are (in my experience in production software environments) more successful than others.
Slashdot Mirror
First, I must declare an interest: I work for Sendmail Inc. which markets an IMAp/POP3 mail server solution.
What you have to ask them is why they want Exchange/Outlook. If you have a good IMAP implementation, you can use Outlook on the front end and your users will get folders on the server + shared folders and syncing and all that stuff.
If you want calendaring, the Outlook/IMAP solution will give you that on an individual basis. You don't get group calendaring, *but* nobody really uses that. I've worked at four companies, two were Exchange shops, one was a Notes shop and my current one uses a product called Meeting Maker. In none of them did people use the group calendaring seriously and my current company is the only one that uses it at all.
Directory access: get an LDAP server - any LDAP server. OpenLDAP is free, but there are also commercial ones with nice admin tools.
Then there is cost: a client access licence for Exchange is about £500 in the UK. My company has just launched an IMAP server which for a thousand users will cost maybe £5 per user, or you can get an open source one.
If you use products that support open standards such as POP, IMAP, LDAP and SMTP then you will not be tied into any manufacturer's products. On the other hand that manufacturer's products *will* have support for the open standards e.g. buy Exchange - you *must* put Outlook on every PC. Buy any IMAP server - you *can* use Outlook on each PC.
If your config was all in a binary format, then your rescue floppy will have a config editor on it, not vi (or as well as vi).
That's the one objection gone, so let's define our common binary format....
Sendmail.conf requires the bat book, in reality bible.
If the Sendmail conf was in an XML file it would still require a bible. The complexity of sendmail configuration arises from the semantics of what the config does, not its syntax.
Random access: read your text config file into memory on app start-up. If it's too big, there's something wrong with your app - rewrite it... Even sendmail reads its entire config into RAM. Backup and recovery: Make a copy of your text file. Better still, manage it with your favourite source code control tool, but make a backup anyway incase your changes screw the source code control tool. Personally I think config files should be edittable with any text editor. You can probably assume a worst case of "vi" although in my early days of working with Unix I did once have to edit a config file with ed because the customer hadn't installed vi and I didn't have time to learn emacs. Of course, being able to change the config with a text editor is no excuse for not having a friendly graphical interface too. The syntax should be simple and easy to understand for a human techy. That may disqualify XML with all its tags and angle brackets etc. I tend to go for a format similar to the old MS ini format. e.g. # this is a comment [section] keyword=value Also, separate files for separate programs. The big problem with the M$ registry is that your program is configured in the same database as all of those nasty and yet essential device drivers and so on.
They used "kernal" in C64s and VIC20s because that's what it was in the Commodore PET - silly.
Anyway, they paid for their mistake by going bankrupt.
Point 1: I believe the guy who stole the Enigma was going to ransom it back to BP or more accurately, he was going to ransom the three rotors having already sent back the rest of the machine.
Point 2: It's too simplistic to say that Alan Turing broke Enigma. Enigma was first cracked by the Polish who were also responsible for inventing the electro-mechanical device know as the Bombe which was used for key recovery. The Poles handed all the info over to the Brits when the Germans introduced two more rotors (i.e. on army and luftwaffe machines, three rotors were chosen from a set of five each day) because they didn't have the resources to cope with the extra complexity of the machine.
Alan Turing's contribution was more to do with improving the existing methods of breaking enigma and countering the Germans' improvements in Enigma. That's not to belittle him. It has been said that his contribution to winning the war was the most important by any individual (unless you count Hitler's monumental incompetance).
OK I've read the article now. Greenspun's idea that a programmer has to work a 70 hour week is based on the premise that he/she has to spend 25 hours a week just coordinating with the other people in the organisation. I would suggest that it is much better to try and reduce the unproductive 25 hours rather than increase the productive 30 hours - or actually in my case 15 hours (my contract is for a 40 hour week). There are lots of techniques for doing this. The best book I've seen on the subject is Steve MaGuire's "Debugging the Development Process" which I would recommend to any aspiring software project manager.
There are several clues in the text of Greenspun's article e.g. a project meeting requiring five managers to attend (hmmm......) which suggest that his company needs a serious look at the way it runs projects. In fairness, he does allude to the fact that this is going on.
I admit I haven't read the article because it's slashdotted at the moment, but having read a lot of the comments I think I'm on safe ground assuming he advocates a 70 hour week for programmers.
There are several reasons why this is a crazy idea. One is the burn out problem. Assuming they're working a 6 day week, that's just under 12 hours a day. There's no way anybody can stay productive at that rate for any length of time. Actually, to put it in perspective, until recently, newly qualified doctors here in the UK had to spend their first year effectively doing slave labour in our hospitals. 100 hour weeks were not uncommon.
Two is the fact that a programmer is working a 12 hour day, activities that normally do not count as work tend to migrate into it. For example, if you have to go to your bank, you might do it in office hours; because you are working long hours, you'll have frequent breaks to do things like play Quake, surf the net, organise your vacation or go and work out for a bit; if you're working late in the evening it is not unreasonable to have something to eat etc etc. I don't know if anybody has done any scientific research into it, but I bet the 12 hour a day programmer spends about as much time actually producing code as the 8 hour a day programmer.
Reason three, Brookes' law states that putting more resource onto a late project makes it later.
The reason for this is twofold:
a) programming tasks are inherently single threaded - only one person can code one module. If you have already broken out the tasks into the most basic units and assigned resource to each one, adding more programmers will have no effect on the schedule except that
b) new programmers rarely come into a project knowing everything they need to be productive, so you have to take your existing resource off production to train the new ones.
If your project is late, there is one way to beat Brookes' law. You can ask your programmers to work longer hours. If they're already working a 12 hour day, this is probably not an option and for reasons 1 and 2 above probably not effective. However, if they are working an 8 hour day, you could ask them to go to 12 hours for short periods (e.g. a couple of weeks).
Personally I value my leisure time far to much to work for any company that insisted on a 70 hour week. Actually it's illegal in the UK and the rest of the European Union.
No they can't because you've encrypted it with the recipient's public key....
You should never consider any e-mail transmitted in clear text to be private. If my doctor was sending such e-mails to me at any place (home or work), I'd take him aside and introduce him to cryptography.
There's lots of stuff in RIP that I disagree with, but frankly, if you are sending stuff across their infrastructure (e- or snail- mail) that you don't want your company to see and you get found out, you deserve to be fired for stupidity.
I thought it would be a fun idea to flame the author, but then I realised lots of other people would be doing it anyway, so it wouldn't be original unless I got first post :-)
They mentioned that other services were having funding problems and for that reason were withdrawing their services
I think they're referring to Line One and others writing to their customers claiming they were spending too much time on line and trying to limit them to 17 hours a week. Apparently they didn't realise that if you have free internet access you will leave it on all the time.
Neither actually, the Commodore 64 and Pet were both produced by a company called.... Commodore. The guy who used to run Commodore (Jack Tramiel) did take over at Atari after he was booted out of Commodore for nearly bankrupting them.
Atari did have some sort of home PC which us Commie owners looked down on with contempt (this was before the ST).
As a Company trading in the UK, Tesco is subject to the Data Protection Act. This means that they have certain obligations wrt any personal data they might collect from you.
As for the particular issue of collecting information about your browser, the DPA says they must discard data as soon as they have finished using it for its legitimate purpose i.e. once the page has been constructed.
As for the fact that the web page only works for two browsers - well that is just bad programming. If I find a page that doesn't work, I always submit a bug report. In software terms, web sites are often very poorly engineered (IMHO) and a little constructive criticism may just possibly improve things a bit.
As it happens, under the usual criteria for judging server OSes (scalability, reliability, security) Linux is not a particulary good server OS - it's just that Windows NT makes it look good.
OTOH, it's cheap and easy to get hold of. There's loads of support available on the Internet and there are lots of applications available which are also cheap or free.
On the desktop, Linux has a big achilles heel in that you don't always have the latest hardware support. Hardware manufacturers put a lot of effort into writing drivers for Windows as 90% of the units they sell will end up in Windows boxes, but with Linux you are reliant on somebody in the Linux community coming up with a driver unless you are a systems programmer.
When I got my new Dell CSx laptop, it came preconfigured to install Windows when I first switched it on. Ok, the process requires four reboots and takes about an hour and a half, but at the end of that the PC and all of its peripherals were functioning perfectly.
Then I came to install RH Linux on the same laptop. The install took about an hour with two reboots (the first one being so I could restart the install in text mode because the RH install usually starts an X-server so that it can look pretty, and the X-server refused to talk to my graphics card). However, at the end of this I had no GUI. XFree86 absolutely refused to do anything with my graphics card as it was too new. I estimate I took about 16 hours or more to get it working. Is the average person going to spend that length of time getting their PC to work? I don't think so. He/she'll format c: and reinstall Windows.
However, in the corporate environment where the IT dept can control both the hardware standards and Linux config, I think it would make an extremely good desktop OS.
RHL 6.1 is old, but so is NT4 sp6 and it outperformed both Win2K and RHL 6.1. Doesn't that crap on the "it's slow cos it's old" argument?
That's a story in Douglas Hofstadter's book "Godel Escher Bach, An Eternal Golden Braid". The particular brand of computer and operating system they were talking about was not mentioned.
Proof mechanisms *are* inherently too limited for real world situations. For a start, how do you prove 1/2 a million lines of code (say). It'll take some time, unless you use an automated proving tool. How do you know you can trust the proving tool? You have to prove it. Even if you have 100% proved the source code is OK, what about the compiler / interpreter? What about the operating system, CPU microcode, the logic design of the chip etc etc etc.
At some point you have got to stop and just trust everything below that level. Taking gcc as an example, how do we know it always produces correct code. Has anybody done any formal tests to prove it? No, but I bet it hardly ever occurs to anybody that their problems may be a result of a compiler bug. Enough people use gcc every day without problems to make it fairly trustworthy. Is trust built on experience any less valuable than trust built on formal methods?
That'll be good. Win9x - well the important bits like the kernel and GDI etc etc - is written in Intel x86 assembler. I foresee that it will be a challenge to port it to a Sparc box.
I know of a hacker called Merl
Who is always programming in Perl
If he was a man
He'd use just Fortran
In fact I think he's a girl.
He means -1 is imaginary in the sense that it is a mathematical abstraction to make it easier to answer questions like what is 1 - 2 ?
You can't have a set of -1 objects, like you can have a set of 1, 2, 3 or even 0 objects.
He does not mean that -1 is a complex number with a real part of 0. Although he was being deliberately confusing.
I thought rockets came before jet propulsion. There was that Goddard guy and the Chinese of course. I'd go for electricity and quantum mechanics for the 20th and probably genetics for the 21st.
Cobol programmers. The default way of storing numbers in Cobol is effectively as a string. All the code to do conversion is done by the compiler and is transparent to the programmer.
Does having a clue about quality include reviewing your output to determine whether, for instance, you have accidentally substituted a "w" for an "f" in the word "filled"?
I can't think of one non trivial piece of software that I use today that was created by a "rogue programmer in the basement". It's all simply too big and complex for one person to write on their own. Even successful Open Source projects follow a methodology (see Eric Raymond's "The Cathedral and the Bazaar").
Good methodologies are designed to protect the project from idiots of all types. These include idiot users, idiot customers, idiot programmers, idiot designers and, most importantly, idiot managers. Some of them are (in my experience in production software environments) more successful than others.