One of the quoted reasons is the fact that terrorism was, thanks to Irish
terrorism and others, far more of a threat to banks and institutions in the
UK. Just look at the "work" of Irish terrorists over the last 25 years, according to the BBC
I worked for a major investment bank in London, and we suffered a couple of
very real
security threats (to the extent of having sniffer dogs running around our feet as we worked) - in each case we were ready to "invoke contingency", and
move trading operations to our backup data centre, some miles away (thankfully it never actually happened for real, but we did a number of tests, and were ready).
Whilst the costs of such an installation would clearly be high, there is a definate need for such offerings, and I suspect we'll see them increase in number, especially with the activities of the "Real IRA" recently.
I read the docs with interest - it's a superb system that will hopefully add another great product to the growing GNU toolset, but I can't help but worry the first version isn't addressing some key demands which would make it "fit" for widespread (commercial?) use.
Why did the developers choose an unscalable approach, ie, a single back end server that tries to do everything itself (why not offload much of the raw data management to a GPL'd SQL server?), this would go a long way to addressing scalability and reliability. Even though they have (sensibly) got a journaled event log in the back end, i still worry about what would happen if the journal itself got corrupted after a failure.
Large scale RDBMS' address this issue head on, and if properly setup, will deal with that sort of issue transparantly. ie. solve only the core problem you're trying to address. And having a data store that multiple systems can connect to opens up redundancy - a key requirement in a system that's managing your directories.
Security is painfully weak outside of the internal model (which sounds strong), limited as they are to the Java RMI implementation. I certainly don't want admin id's, passwords and RMI's for something as crucial as this wizzing over my networks, trusted or not - it's a risk. VPN's, IP6 and SSH could ultimately be unleashed on this problem, but i fear the developers have decided to leave it on the backburner for now.
All said and done, it sounds like a great version 1.0 (and I take my hat off to the developers, despite my criticisms above), but I think it needs some solid progress in the areas above before it becomes a commonly used infrastructure tool.
I couldn't comment on any specific geek charities per se, but UK residents may be interested in allaboutgiving.org - which gives lots of info about available charities.
Mmmmm. Unix. Don't you just love it. Now, how would a PC user have done it...;-)
Current 'time' in secs since 1 Jan 1970:
rleyton[1042] date '+%s' 949514155
Crank up good 'ol bc, work out how many seconds until the billionth one...
rleyton[1043] bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1000000000-949514155 50485845
Then back to good 'ol date, and ask it to do the hard work:
rleyton[1044] date --date '50485845 seconds' Sat Sep 8 21:47:05 EDT 2001
I received an e-mail from William Fallows, the US editor of Computergram, giving me permission to post the complete article, which you'll find below.
For that, I figure it's worth allowing Computerwire a plug - I received an e-mail from Richard MacPherson, the West Coast Accounts manager of Computerwire, offering businesses a 10 day free trial of their various publications. See the web site or send him an e-mail for more detail. SUN PLANS OPEN SOURCE SOLARIS Sun Microsystems Inc is working on a strategy that will enable it to move its Solaris Unix to the open source development model without stepping on the toes of the Linux community and being branded the evil empire. It says that its dilemma is that "Linux is good for Solaris, but that Linux is not a corporate community" and "our intentions must not be misunderstood." One route would be to turn over Solaris intellectual property and source for development by the open source community but retain all branding, packaging and testing considerations, as with its Java community source model. However, Solaris isn't as young as Java and Sun is not sure what the effect might be on its large code set and hefty installed base. Other major considerations include the paper chase of royalty, IP and branding rights in the agreements it has made since buying out its Unix license from Novell Inc in 1994 for $82.5m. It is looking for anything that could prevent it taking Solaris open source, such as rights that may belong to other companies. Sun, which is already making Solaris APIs compatible with Linux, says it is also still working out how it will market the initiative and what image it wants to present. It expects to move quickly but until there's a method "we can't say bombs away," it says.
I worked for a major investment bank in London, and we suffered a couple of very real security threats (to the extent of having sniffer dogs running around our feet as we worked) - in each case we were ready to "invoke contingency", and move trading operations to our backup data centre, some miles away (thankfully it never actually happened for real, but we did a number of tests, and were ready).
Whilst the costs of such an installation would clearly be high, there is a definate need for such offerings, and I suspect we'll see them increase in number, especially with the activities of the "Real IRA" recently.
Why did the developers choose an unscalable approach, ie, a single back end server that tries to do everything itself (why not offload much of the raw data management to a GPL'd SQL server?), this would go a long way to addressing scalability and reliability. Even though they have (sensibly) got a journaled event log in the back end, i still worry about what would happen if the journal itself got corrupted after a failure.
Large scale RDBMS' address this issue head on, and if properly setup, will deal with that sort of issue transparantly. ie. solve only the core problem you're trying to address. And having a data store that multiple systems can connect to opens up redundancy - a key requirement in a system that's managing your directories.
Security is painfully weak outside of the internal model (which sounds strong), limited as they are to the Java RMI implementation. I certainly don't want admin id's, passwords and RMI's for something as crucial as this wizzing over my networks, trusted or not - it's a risk. VPN's, IP6 and SSH could ultimately be unleashed on this problem, but i fear the developers have decided to leave it on the backburner for now.
All said and done, it sounds like a great version 1.0 (and I take my hat off to the developers, despite my criticisms above), but I think it needs some solid progress in the areas above before it becomes a commonly used infrastructure tool.
Ok, so the book might not be out yet, and i've no idea about t-shirts, but the movie is here, and lots more besides at the good old BBC.
You can also sign up for apply for a Charity Card - which allows you to donate online.
In my experience, it's the easiest and most tax-efficient way of giving to charity in the UK.
This glitch is well known, but there is a fix. Take a look at Sunsolve, (SRD B 20427). (Not sure if this is publicly available).
Mmmmm. Unix. Don't you just love it. Now, how would a PC user have done it... ;-)
Current 'time' in secs since 1 Jan 1970:
rleyton[1042] date '+%s'
949514155
Crank up good 'ol bc, work out how many seconds until the billionth one...
rleyton[1043] bc
bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
1000000000-949514155
50485845
Then back to good 'ol date, and ask it to do the hard work:
rleyton[1044] date --date '50485845 seconds'
Sat Sep 8 21:47:05 EDT 2001
(Redhat Linux 2.0.36 incase you're curious).
I should add, next year: Sat Sep 8 21:47:20 EDT 2001 Doh!
Don't forget that the 1,000,000,000th second of Unix time hits us on the evening of Saturday, Sep 8th (EST)! Get that champagne on ice... ;^)
It was Winston Churchill.
I received an e-mail from William Fallows, the US editor of Computergram, giving me permission to post the complete article, which you'll find below.
For that, I figure it's worth allowing Computerwire a plug - I received an e-mail from Richard MacPherson, the West Coast Accounts manager of Computerwire, offering businesses a 10 day free trial of their various publications. See the web site or send him an e-mail for more detail.
SUN PLANS OPEN SOURCE SOLARIS
Sun Microsystems Inc is working on a strategy that will enable it to move its Solaris Unix to the open source development model without stepping on the toes of the Linux community and being branded the evil empire. It says that its dilemma is that
"Linux is good for Solaris, but that Linux is not a corporate community" and "our intentions must not be misunderstood." One route would be to turn over Solaris intellectual property and source for development by the open source community but retain all branding, packaging and testing considerations, as with its Java community source model. However, Solaris isn't as young as
Java and Sun is not sure what the effect might be on its large code set and hefty installed base. Other major considerations include the paper chase of royalty, IP and branding rights in the agreements it has made since buying out its Unix license from Novell Inc in 1994 for $82.5m. It is looking for anything that could prevent it taking Solaris open source, such as rights that may belong to other companies. Sun, which is already making Solaris APIs compatible with Linux, says it is also still working out how it will market the initiative and what image it wants to present. It expects to move quickly but until there's a method "we can't say bombs away," it says.