Usually, they are just not obtainable - at least in the uk. We recently *had* to upgrade one of our servers just so we could allocate its licences to the rest of the farm - as 4.11 licences are no longer on sale here.
Netware 3 is awkward for licencing anyhow - in contrast with NW4 (where each licence is a separate file and you can move them from server to server, provided you respect the chain and don't try installing any one twice) NW3 had the licence hardcoded into the server.exe, and an "upgrade licence" was a proggy that actually PATCHED that exe with the new licence (after getting an auth code via fax from Novell)
Personally, I wouldn't touch 3.x again if I was paid to - 4 was just a quantum leap up from there. However, 5 isn't much if any of an improvement (it has virtual memory and a gui, yes, but I don't need those) And I could do without *having* to upgrade my software just because Novell decide they want me to. --
Many schools continue to use Netware because of the huge educational discounts given them. It would cost too much money to switch to NT, and Linux servers don't have good enough Windows compatibility for them.
Netware is also much more stable and secure - NDS being a wonderful way to administer multiserver networks (AD sucks, and NDS on NT sucks almost as much, and involves paying TWICE for each user, once to M$oft and once to Not-well). But for straight File-and-print from Windoze boxen, Nothing much beats a Novell server.
Do not EVER run anything on it though - particularly databases; pre-5.0 the lack of virtual memory was a killer, and even in 5.0 the performance you will get is so poor you are better off buying a separate box and running your DB under linux. --
"a program called DeCSS, which disables the Content Scramble System (CSS) that prevents consumers from making copies of DVDs."
*sigh*
will they *ever* get the idea? you can copy DVDs just fine without DeCSS - it is not removing copy protection, it is removing WATCH protection. --
Unless the compressor is run by wind, solar, or hydro power it probably results in a net increase in total emissions. Almost certainly, yes. however, given that the compression can take place at a fixed site, and is pretty much danger free, there is no reason you *can't* market solar-powered compressors for the home user. Each car owner could produce their own compressed air at home, unattended, and transfer it to their vehicle on an evening. Firms could run compressors for the convenience of their employees, and so forth. --
For the purposes you describe, I agree, Linux makes a wonderful fit. I still assert, however, that my original comment has a place in this discussion, given all the posts about people's pacemakers crashing and life support systems going into microsoft blue-screen mode. My point was that neither microsoft nor linux should ever find their way into true safety-critical applications like the ones i just mentioned.
Yep, the usual avalanche of users who don't read the links (or even the full post) and just type away at whatever the title suggests to them. I am suprised we didn't get some discussion of open-sourcing $DRUG for making them at home with a Junior Chemistry set..... --
Here's a little bit of reality, try not to chew it too hard.
Linux isn't a real-time operating system. It makes a great real-time controller, but it just doesn't have the granularity to do real time. Certainly true - but not actually important. The main usages of computer software would be in patient record keeping, drug prescription advice (and interactions/side effects) and "expert system" style software, both for self-triage and as a backup check at the data entry stage (example - patient is suddenly prescribed a lethal dosage of drugs; certainly warrants a "are you sure you want to do this" box).
Odds of any OSS software being developed that require real-time interrupt support are almost non-existent - such software will continue to come bundled with the hardware it controls, and the best you can hope for is the ability to download treatment information into it in a common format. --
How is this an assault on PERSONAL PRIVACY? You are sending mail and surfing while on company time and you whine because your employer wants to see how you are using it's resources. If this were the government monitoring it's citizens I could understand, but not a company monitoring it's employees.
Personally? I start work at 8:30 am, finish well after 7pm, five days a week (weekends optional). No-one (with the possible exclusion of you, it seems) honestly believes you can cut that big a chunk out of your life, totally excluding any personal business, especially if you are married with children. Excessive personal time during working hours is usually frowned upon, but arranging doctor's appointments, being contacted by your offspring's school and/or arranging your weekend's entertainments is usually accepted as a small overhead for being in business. Employers may well expect such things to take second place to working practices, and in particular outgoing calls should be in breaks rather than while on duty, but it *should* be deeply suspect if an employer decided to pass over an employee for promotion, based on the twice she has phoned her doctor to arrange a pregnancy test..... --
Actually, that site is a-celebrity.com, I know this because I went to celebrity.com and it was clearly porn. Not bad I might add. But I was in search of some backgrounds. So I found the page you were talking about and the correct address is a-celebrity.com and there were some nice backgrounds there, found a new one for xdm. thanks
a-celebrity.com would be blocked under the
Lingerie setting, as an earlier poster said. A couple of clicks gave me this: Alyssa-Milano - certainly a nice piccy, and definitely not pr0n, but it falls inside the list of subjects that were requested to be blocked... --
Last one I had (which my wife gave to one of her friends:+) didn't need any special Linux drivers - the think looked and acted like any other PS/2 or serial mouse, and worked fine on the standard two-button mouse drivers. --
Firstly it's RIPA, not RIP, and you could have at least made a lame `Rest in Peace` joke.
As I understand it, it was the RIP bill until it passed, at which point it became an Act of Parliment (the RIP Act)
Sorry, ran out of lame RIP jokes already discussing this abomination... --
What i want to know, is how do they think they have the right to affect people in other countries, the DMCA is a U.S. law, not worldwide, the MPAA has no right to use that law against anybody else in the world! ...Particularly as the US was late in the game to recognise Copyright at all... --
That's an acronym of DOS that would never have occured to me...
Oh, I dunno - Descent Operating System possibly - although I tend to use mine as a DOOM2 operating System:+) --
Re:Negative people on slashdot.
on
IRC Improvements
·
· Score: 2
All valid points. But aren't 1 and 2 inherent problems with any public key system?
Well, (1) is inherent in single-ended PK systems - If you used (for example) PGP keys in the mix, then you would have to compromise all the PGP keyservers; single-endedness is one of the known weaknesses of SSL.
(2) is a specific weakness in IRC packages - I am not saying that the software you choose does have that weakness, just that many security loopholes have been found so far, and more will be in the future. IRC software is often not secured against such attacks, as it isn't normally security-critical.
3 is probably the best criticism, and it will be hard to address. What about this, for each person you want to talk to on the channel, you select their public key out of your trusted keyring, and anyone in the channel you don't trust, you can just not select their key.
Yep, that was (roughly) the approach that occurred to me too. However, I was thinking in terms of Session Keys for a channel - so (assuming a PGP overlay) the first person on channel generates a session key; The second person online must request the key from the channel founder, via a PK encrypted request and reply (keys from the public servers, not implicit of trust). If the two have an existing relationship, the channel is marked trusted; if the two don't have an existing trust relationship, but the channel founder hands over the key, then the channel is marked secure-but-distrusted; if the channel founder refuses the key request, the channel remains dormant, but the new user remains on the external waiting-for-admittance list (structurally, this will look like a join-refused to any external IRC package; some new commands would need to be added between the IRC package and the interface module handling the encryption so the user could check his waiting status)
Ok, now a third party joins; if he is trusted, then he gets the session key and the channel owner sends to him the current waiting list; anyone on that list HE trusts he then contacts and invites to the channel, thus maintaining the trusted status; there is some additional stuff I have mapped out about doing a trust-check to upgrade secure-but-distrusted to trusted; basically, there is a rekey event, and it is handed to all the trusted users via the "hard" trust relationships; if any untrusted users remain, they either receive the key via the old session key (a soft upgrade attempt) or are excluded from the channel (a hard upgrade)
This of course requires a lot of client modifications, but if we came up with something standard, I am sure Kahled would be a willing listener, one who doesn't have to follow stupid US encryption laws either.
One of the advantages of the scheme I came up with was it could be done entirely from a "gateway" app, similar to the one used to provide SSH functionality to apps that don't support SSH. As it would inherently understand IRC, it could handle ping/pong events, the encryption/keying and rekeying itself, and support "additional" commands that trigger events (similar to bot ! commands, but not displayed on the channel)
--
Yep, the Scramdisk NT version still hasn't been released - however, E4M will support scramdisks under NT for the time being, and you can crossgrade to a true Scramdisk client later (which will also give you Win9x and Linux cross-support.
However, both of these options are per-virtual-disk, not per-file - I am not sure if this is what you want (there is no option to move a single file while still encrypted, you need to unlock the volume and copy the file (unprotected, or via PGP) to it's new home. --
Re:Negative people on slashdot.
on
IRC Improvements
·
· Score: 2
My god... I can't believe you people sometimes. You think carnivore is bad, and you pontificate about encryption being the only way to secure your email from the Government's prying eyes. Then this story comes out, and of the comments so far, no one has anything good to say about it.
Encryption is a double-edged sword - It protects you against evesdropping when working correctly, but unfortunately it also makes you *feel* secure. The immediate question then has to be - if you feel secure, and start divulging secrets you wouldn't trust to an insecure channel, then under what circumstances could someone else gain access to that information? when will your trust in the security of the channel let you down? As I see it, there are several points of attack:
Tunnel insecurity or MitM attacks Someone could compromise the security of the channel between you and the server, either by getting the server's key, getting you to switch to an insecure channel, or intercepting the initial communications so as to set up TWO encrypted channels, one from you to him, and one from him to the server.
client insecurity Someone could hack, exploit loopholes in or plain replace your client with one that lets him spy. This also effects any logfiles you keep - you may think of them as historic data, but they are really a realtime window into what you can see, on a second-by-second basis
Server insecurity This is a biggie, and needs dividing up
Abuse of priviledge
Server admins could (for example) activate logging on a channel to see what was said there - or create an invisible client for themselves so they are "on" the channel without being seen
Exploits against the server A blackhat attacker could exploit weaknesses in the server software to gain admin priviledges, then abuse them as above
These are just the first few points that spring to mind, and yes, the #suid people have done well (and more importantly, have gotten off their backsides and written this stuff rather than just sitting around saying how good it would be if someone did) but security, like fire safety, is something that needs a good hard look and frequent inspection. --
There is an ongoing discussion on one of my email lists (well, it gives us something to talk about now the RIP bill has been stamped into law)
It appears Demon Internet (a largish ISP here in the UK) received the letter too, and was sufficiently paniced by it to sent out a "prove you are innocent or else" letter to it's customer. --
I am leaving my local encryption until the imminent release of Scramdisk for linux - that way I will be able to open the *same* encrypted data under Win9x too. Currently, I can only really do that with PGP.... --
I think a lot depends on the circumstances. At our company, voicemail tends to be tied to individual handsets - so that stays until the desk is reassigned, at which point any outstanding voicemail is cleared, a new announce for the new user is set up and so forth.
Email is more marginal - if we are informed of a leaver, email is disconnected from the external gateway (internet email inbound will bounce) but is left in existance for a few weeks - many managers will have access to their leaver's account to clear up any outstanding stuff in the system. Unless requested otherwise, the email account is deleted when the network account is deleted.
Network accounts are disabled when a given user leaves (again, provided we are notified!) In addition, we audit account use - any Network account that hasn't been used in two months flags up an alert, and we contact the department to ask why.
Obviously, all of this applies to ordinary user accounts. for Techie accounts, it becomes more interesting. Email and network are disabled, as above, and any remote access keys are disabled too. However, there are three possibilities.
The techie left on friendly terms Any user accounts he held have their passwords disabled, but root accounts are left to expire and be cycled normally; Unless given a good reason to assume otherwise, this techie may want to look for references from us, possibly even another job in the future.
Techie left on unfriendly terms, without warning Unfriendly does not have to mean removed for cause; redundancy is equally valid. In this case, all root passwords (even ones he theoretically didn't know) are changed at once; account lists are searched for dubious accounts with either permissions they shouldn't have or with access entries matching the techie's pc.
Techie left on unfriendly terms with unsupervised access to machines nightmare scenario; User has been expelled from the building for cause, has resigned for reasons that are likely to indicate resentment of the company or individual managers (contributatory dismissal for example) or knew he was being downsized in advance and wasn't happy about it.
This has to be any sysadmin's worst nightmare - the system is totally screwed. any or all servers may be rootkitted; timebombs or backdoors may exist in any utility or system program, backups may be corrupt, deliberate errors added in data that may take years to identify and fix. Procedure if this ever happened would be extreme - backup server (normally used for development testing) would be backed up then completely reinstalled from original media; new accounts set up and validated, software reinstalled and databases transferred. Backup server would become live server, live server pair would go offline and suffer similar indignities, after forensic examination by contract experts; user would be carried on payroll and his user accounts left untouched until the whole of SAP R/3's user code was validated by the DEV team; and even then, you could never be 100% sure.
Luckily we have never had a case of the nightmare scenario - but the procedures we could not afford to not follow would be massively more expensive and disruptive than even our worst-case disaster recovery plan. --
Ok, so I have had a look at the announcement, and the first thing that sprang out at me was the qualification requirement. In order to qualify for the "relaxed" rules, you need to be a MS select or Enterprise Agreement licencee - normal mortals (and my employer flies under this flag even though we have over four hundred PCs in use) get all their licences bundled with the machines, and only replace OSs when they replace machines. However, our site *also* has a full set of custom apps, so ghost-rollout of a new installed-base of replacement machines (hardware upgrade, needed for the new generation of MS office apps) is needed, in about blocks of fifty.... --
That's odd - I thought you had to explicitly ask for one of these - have they started sending them out to random addresses in the US (even though I can't find one in.uk for love nor money?) --
If a Solaris device driver is released with Linux/x86 source, its a violation. They must release the source to the Solaris driver bits, which they don't have when they use this, because it only converts the binary.
Actually, I would dispute this - a compiler is a tool which takes a specially formatted input file (C sourcecode for example) and outputs linkable output. If this SUN tool takes specially formatted input (the published binaries) and outputs runnable code, then the published binaries ARE the source. any variant of the GPL that states explicitly the source must be C in human readable form would be one I am not familar with; one that insisted that any GPLed source was compiled ONLY with a open source compiler would be discarded as unworkable.
Yes, SUN could have written a compiler that takes C source and compiles it; that it takes Binaries and recompiles them is actually an *ad*vantage, as it allows closed source drivers to be converted as well. I am sorry, but I just can't see what the fuss is about. --
Simply put, there already existed other alternatives to RSA, provably just-as or more secure than RSA, which were unencumbered by patents. (The most notable would be El Gamal, which went into the public domain in 1997.)
This is of course true - but RSA is popular and is easy to explain to a non-techie; However, it may be worth noting that RSA has *always* been free outside of America - however, the other part of "classic" PGP (IDEA) is still patented worldwide, and will be for several years yet. --
Unfortunately, no. The breakline between your cablemodem service and your cabletv service isn't where you think - it is that you are hiring the cable service (which contains both modem and tv support, and bundles the minimum channels) and an ISP (which uses the modem bandwidth). One cable company can support multiple ISPs if need be, and no ISP is force-tied to one Cable company - they can support several. However, if they say that the only cable company in your area whose fibre they connect to is the one you are currently using, you can't force them to support more. --
here is nothing about DVD technology that inherently couples a specific DVD to a specific player. I can buy a Sony produced DVD and play it on any hardware player in the market and any software player I can get my hands on. Actually, you can't. All DVD players are made by licencees of the technology from the DVD manufacturers; there is no such thing as a non-licenced DVD drive. --
Slashdot Mirror
Usually, they are just not obtainable - at least in the uk. We recently *had* to upgrade one of our servers just so we could allocate its licences to the rest of the farm - as 4.11 licences are no longer on sale here. Netware 3 is awkward for licencing anyhow - in contrast with NW4 (where each licence is a separate file and you can move them from server to server, provided you respect the chain and don't try installing any one twice) NW3 had the licence hardcoded into the server.exe, and an "upgrade licence" was a proggy that actually PATCHED that exe with the new licence (after getting an auth code via fax from Novell) Personally, I wouldn't touch 3.x again if I was paid to - 4 was just a quantum leap up from there. However, 5 isn't much if any of an improvement (it has virtual memory and a gui, yes, but I don't need those) And I could do without *having* to upgrade my software just because Novell decide they want me to.
--
Many schools continue to use Netware because of the huge educational discounts given them. It would cost too much money to switch to NT, and Linux servers don't have good enough Windows compatibility for them.
Netware is also much more stable and secure - NDS being a wonderful way to administer multiserver networks (AD sucks, and NDS on NT sucks almost as much, and involves paying TWICE for each user, once to M$oft and once to Not-well). But for straight File-and-print from Windoze boxen, Nothing much beats a Novell server.
Do not EVER run anything on it though - particularly databases; pre-5.0 the lack of virtual memory was a killer, and even in 5.0 the performance you will get is so poor you are better off buying a separate box and running your DB under linux.
--
"a program called DeCSS, which disables the Content Scramble System (CSS) that prevents consumers from making copies of DVDs."
*sigh*
will they *ever* get the idea? you can copy DVDs just fine without DeCSS - it is not removing copy protection, it is removing WATCH protection.
--
Unless the compressor is run by wind, solar, or hydro power it probably results in a net increase in total emissions.
Almost certainly, yes. however, given that the compression can take place at a fixed site, and is pretty much danger free, there is no reason you *can't* market solar-powered compressors for the home user. Each car owner could produce their own compressed air at home, unattended, and transfer it to their vehicle on an evening. Firms could run compressors for the convenience of their employees, and so forth.
--
For the purposes you describe, I agree, Linux makes a wonderful fit. I still assert, however, that my original comment has a place in this discussion, given all the posts about people's pacemakers crashing and life support systems going into microsoft blue-screen mode. My point was that neither microsoft nor linux should ever find their way into true safety-critical applications like the ones i just mentioned.
Yep, the usual avalanche of users who don't read the links (or even the full post) and just type away at whatever the title suggests to them. I am suprised we didn't get some discussion of open-sourcing $DRUG for making them at home with a Junior Chemistry set.....
--
Linux isn't a real-time operating system. It makes a great real-time controller, but it just doesn't have the granularity to do real time.
Certainly true - but not actually important. The main usages of computer software would be in patient record keeping, drug prescription advice (and interactions/side effects) and "expert system" style software, both for self-triage and as a backup check at the data entry stage (example - patient is suddenly prescribed a lethal dosage of drugs; certainly warrants a "are you sure you want to do this" box).
Odds of any OSS software being developed that require real-time interrupt support are almost non-existent - such software will continue to come bundled with the hardware it controls, and the best you can hope for is the ability to download treatment information into it in a common format.
--
How is this an assault on PERSONAL PRIVACY? You are sending mail and surfing while on company time and you whine because your employer wants to see how you are using it's resources. If this were the government monitoring it's citizens I could understand, but not a company monitoring it's employees.
Personally? I start work at 8:30 am, finish well after 7pm, five days a week (weekends optional). No-one (with the possible exclusion of you, it seems) honestly believes you can cut that big a chunk out of your life, totally excluding any personal business, especially if you are married with children. Excessive personal time during working hours is usually frowned upon, but arranging doctor's appointments, being contacted by your offspring's school and/or arranging your weekend's entertainments is usually accepted as a small overhead for being in business. Employers may well expect such things to take second place to working practices, and in particular outgoing calls should be in breaks rather than while on duty, but it *should* be deeply suspect if an employer decided to pass over an employee for promotion, based on the twice she has phoned her doctor to arrange a pregnancy test.....
--
Actually, that site is a-celebrity.com, I know this because I went to celebrity.com and it was clearly porn. Not bad I might add. But I was in search of some backgrounds. So I found the page you were talking about and the correct address is a-celebrity.com and there were some nice backgrounds there, found a new one for xdm. thanks
a-celebrity.com would be blocked under the Lingerie setting, as an earlier poster said. A couple of clicks gave me this: Alyssa-Milano - certainly a nice piccy, and definitely not pr0n, but it falls inside the list of subjects that were requested to be blocked...
--
Last one I had (which my wife gave to one of her friends :+) didn't need any special Linux drivers - the think looked and acted like any other PS/2 or serial mouse, and worked fine on the standard two-button mouse drivers.
--
As I understand it, it was the RIP bill until it passed, at which point it became an Act of Parliment (the RIP Act)
Sorry, ran out of lame RIP jokes already discussing this abomination...
--
What i want to know, is how do they think they have the right to affect people in other countries, the DMCA is a U.S. law, not worldwide, the MPAA has no right to use that law against anybody else in the world!
...Particularly as the US was late in the game to recognise Copyright at all...
--
That's an acronym of DOS that would never have occured to me... :+)
Oh, I dunno - Descent Operating System possibly - although I tend to use mine as a DOOM2 operating System
--
Well, (1) is inherent in single-ended PK systems - If you used (for example) PGP keys in the mix, then you would have to compromise all the PGP keyservers; single-endedness is one of the known weaknesses of SSL.
(2) is a specific weakness in IRC packages - I am not saying that the software you choose does have that weakness, just that many security loopholes have been found so far, and more will be in the future. IRC software is often not secured against such attacks, as it isn't normally security-critical.
3 is probably the best criticism, and it will be hard to address. What about this, for each person you want to talk to on the channel, you select their public key out of your trusted keyring, and anyone in the channel you don't trust, you can just not select their key.
Yep, that was (roughly) the approach that occurred to me too. However, I was thinking in terms of Session Keys for a channel - so (assuming a PGP overlay) the first person on channel generates a session key; The second person online must request the key from the channel founder, via a PK encrypted request and reply (keys from the public servers, not implicit of trust). If the two have an existing relationship, the channel is marked trusted; if the two don't have an existing trust relationship, but the channel founder hands over the key, then the channel is marked secure-but-distrusted; if the channel founder refuses the key request, the channel remains dormant, but the new user remains on the external waiting-for-admittance list (structurally, this will look like a join-refused to any external IRC package; some new commands would need to be added between the IRC package and the interface module handling the encryption so the user could check his waiting status)
Ok, now a third party joins; if he is trusted, then he gets the session key and the channel owner sends to him the current waiting list; anyone on that list HE trusts he then contacts and invites to the channel, thus maintaining the trusted status; there is some additional stuff I have mapped out about doing a trust-check to upgrade secure-but-distrusted to trusted; basically, there is a rekey event, and it is handed to all the trusted users via the "hard" trust relationships; if any untrusted users remain, they either receive the key via the old session key (a soft upgrade attempt) or are excluded from the channel (a hard upgrade)
This of course requires a lot of client modifications, but if we came up with something standard, I am sure Kahled would be a willing listener, one who doesn't have to follow stupid US encryption laws either.
One of the advantages of the scheme I came up with was it could be done entirely from a "gateway" app, similar to the one used to provide SSH functionality to apps that don't support SSH. As it would inherently understand IRC, it could handle ping/pong events, the encryption/keying and rekeying itself, and support "additional" commands that trigger events (similar to bot ! commands, but not displayed on the channel)
--
Yep, the Scramdisk NT version still hasn't been released - however, E4M will support scramdisks under NT for the time being, and you can crossgrade to a true Scramdisk client later (which will also give you Win9x and Linux cross-support.
However, both of these options are per-virtual-disk, not per-file - I am not sure if this is what you want (there is no option to move a single file while still encrypted, you need to unlock the volume and copy the file (unprotected, or via PGP) to it's new home.
--
Encryption is a double-edged sword - It protects you against evesdropping when working correctly, but unfortunately it also makes you *feel* secure. The immediate question then has to be - if you feel secure, and start divulging secrets you wouldn't trust to an insecure channel, then under what circumstances could someone else gain access to that information? when will your trust in the security of the channel let you down? As I see it, there are several points of attack:
- Tunnel insecurity or MitM attacks
- client insecurity
- Server insecurity
- Abuse of priviledge
- Exploits against the server
These are just the first few points that spring to mind, and yes, the #suid people have done well (and more importantly, have gotten off their backsides and written this stuff rather than just sitting around saying how good it would be if someone did) but security, like fire safety, is something that needs a good hard look and frequent inspection.Someone could compromise the security of the channel between you and the server, either by getting the server's key, getting you to switch to an insecure channel, or intercepting the initial communications so as to set up TWO encrypted channels, one from you to him, and one from him to the server.
Someone could hack, exploit loopholes in or plain replace your client with one that lets him spy. This also effects any logfiles you keep - you may think of them as historic data, but they are really a realtime window into what you can see, on a second-by-second basis
This is a biggie, and needs dividing up
Server admins could (for example) activate logging on a channel to see what was said there - or create an invisible client for themselves so they are "on" the channel without being seen
A blackhat attacker could exploit weaknesses in the server software to gain admin priviledges, then abuse them as above
--
There is an ongoing discussion on one of my email lists (well, it gives us something to talk about now the RIP bill has been stamped into law)
It appears Demon Internet (a largish ISP here in the UK) received the letter too, and was sufficiently paniced by it to sent out a "prove you are innocent or else" letter to it's customer.
--
I am leaving my local encryption until the imminent release of Scramdisk for linux - that way I will be able to open the *same* encrypted data under Win9x too. Currently, I can only really do that with PGP....
--
Email is more marginal - if we are informed of a leaver, email is disconnected from the external gateway (internet email inbound will bounce) but is left in existance for a few weeks - many managers will have access to their leaver's account to clear up any outstanding stuff in the system. Unless requested otherwise, the email account is deleted when the network account is deleted.
Network accounts are disabled when a given user leaves (again, provided we are notified!) In addition, we audit account use - any Network account that hasn't been used in two months flags up an alert, and we contact the department to ask why.
Obviously, all of this applies to ordinary user accounts. for Techie accounts, it becomes more interesting. Email and network are disabled, as above, and any remote access keys are disabled too. However, there are three possibilities.
- The techie left on friendly terms
- Techie left on unfriendly terms, without warning
- Techie left on unfriendly terms with unsupervised access to machines
Luckily we have never had a case of the nightmare scenario - but the procedures we could not afford to not follow would be massively more expensive and disruptive than even our worst-case disaster recovery plan.Any user accounts he held have their passwords disabled, but root accounts are left to expire and be cycled normally; Unless given a good reason to assume otherwise, this techie may want to look for references from us, possibly even another job in the future.
Unfriendly does not have to mean removed for cause; redundancy is equally valid. In this case, all root passwords (even ones he theoretically didn't know) are changed at once; account lists are searched for dubious accounts with either permissions they shouldn't have or with access entries matching the techie's pc.
nightmare scenario; User has been expelled from the building for cause, has resigned for reasons that are likely to indicate resentment of the company or individual managers (contributatory dismissal for example) or knew he was being downsized in advance and wasn't happy about it.
This has to be any sysadmin's worst nightmare - the system is totally screwed. any or all servers may be rootkitted; timebombs or backdoors may exist in any utility or system program, backups may be corrupt, deliberate errors added in data that may take years to identify and fix.
Procedure if this ever happened would be extreme - backup server (normally used for development testing) would be backed up then completely reinstalled from original media; new accounts set up and validated, software reinstalled and databases transferred. Backup server would become live server, live server pair would go offline and suffer similar indignities, after forensic examination by contract experts; user would be carried on payroll and his user accounts left untouched until the whole of SAP R/3's user code was validated by the DEV team; and even then, you could never be 100% sure.
--
the books by Niccolo Machiavelli may be found online here: http://digital.library.upenn.edu/webbin/book/searc h?author=Nic colo+Machiavelli+&amode=words&title=&tmode=words
--
Ok, so I have had a look at the announcement, and the first thing that sprang out at me was the qualification requirement. In order to qualify for the "relaxed" rules, you need to be a MS select or Enterprise Agreement licencee - normal mortals (and my employer flies under this flag even though we have over four hundred PCs in use) get all their licences bundled with the machines, and only replace OSs when they replace machines. However, our site *also* has a full set of custom apps, so ghost-rollout of a new installed-base of replacement machines (hardware upgrade, needed for the new generation of MS office apps) is needed, in about blocks of fifty....
--
That's odd - I thought you had to explicitly ask for one of these - have they started sending them out to random addresses in the US (even though I can't find one in .uk for love nor money?)
--
If a Solaris device driver is released with Linux/x86 source, its a violation. They must release the source to the Solaris driver bits, which they don't have when they use this, because it only converts the binary.
Actually, I would dispute this - a compiler is a tool which takes a specially formatted input file (C sourcecode for example) and outputs linkable output. If this SUN tool takes specially formatted input (the published binaries) and outputs runnable code, then the published binaries ARE the source. any variant of the GPL that states explicitly the source must be C in human readable form would be one I am not familar with; one that insisted that any GPLed source was compiled ONLY with a open source compiler would be discarded as unworkable.
Yes, SUN could have written a compiler that takes C source and compiles it; that it takes Binaries and recompiles them is actually an *ad*vantage, as it allows closed source drivers to be converted as well. I am sorry, but I just can't see what the fuss is about.
--
Simply put, there already existed other alternatives to RSA, provably just-as or more secure than RSA, which were unencumbered by patents. (The most notable would be El Gamal, which went into the public domain in 1997.)
This is of course true - but RSA is popular and is easy to explain to a non-techie; However, it may be worth noting that RSA has *always* been free outside of America - however, the other part of "classic" PGP (IDEA) is still patented worldwide, and will be for several years yet.
--
Unfortunately, no. The breakline between your cablemodem service and your cabletv service isn't where you think - it is that you are hiring the cable service (which contains both modem and tv support, and bundles the minimum channels) and an ISP (which uses the modem bandwidth). One cable company can support multiple ISPs if need be, and no ISP is force-tied to one Cable company - they can support several. However, if they say that the only cable company in your area whose fibre they connect to is the one you are currently using, you can't force them to support more.
--
here is nothing about DVD technology that inherently couples a specific DVD to a specific player. I can buy a Sony produced DVD and play it on any hardware player in the market and any software player I can get my hands on.
Actually, you can't. All DVD players are made by licencees of the technology from the DVD manufacturers; there is no such thing as a non-licenced DVD drive.
--