That depends on what you are intending to do with the directory. I have seen many companies who have well over 100,000 objects per container when they were designing (a) an external-facing directory, or (b) a very large identity vault for use with Novell Identity Manager. I probably wouldn't design a tree with this many objects in a single container that was partitioned to replicate over any type of WAN, but if all replicas are on the same high-speed backbone, this type of design isn't a problem.
eDirectory 8.7 can handle this type of scalability without breaking a sweat - as long as the hardware and network are (a) up to the task, and (b) configured correctly.
I think we're both "suffering" (not really the right word here, but I can't think of one that fits better here) from the same thing - being tired of uneducated points of view (no, I'm not saying yours is - I've reread the comments and - mea culpa - I misread the direction of the discussion). We both seem to share the same intolerance for ignorance.
While I am a Novell die-hard (I in fact work for Novell), I have extensive experience with Active Directory, particularly in large scale designs and deployments. I also have personally met with and discussed Active Directory with Microsoft's product management and engineering managers, and a good friend of mine was in charge of the team that instrumented Active Directory for WMI (which is how Active Directory is monitored by MOM). Incidentally, that person used to work for Novell.
Simply put, I do not come from a position of ignorance on either product, but rather from an in-depth knowledge gained through detailed discussions with the people who have worked on the design of both products. My comment was neither emotional nor factless; it was based on my experience and discussions with people who know.
First off, NDS is an old Novell product; the current product is called eDirectory. So let's start by debating the proper products here. This is a myth that Microsoft continues to propagate even today with their competitive analysis; they refuse to compare to eDirectory because they know that in a feature-by-feature comparison, they lose. They prefer to compare to a product that had limitations of around 5000 objects per container, rather than one that supports millions of objects per container without breaking a sweat.
Coming back to the point of whether AD is a knock-off of NDS or eDirectory, though. It would be fair to say that one product released after another product that competes in the same space is going to incorporate design decisions that make the products comparable. I seriously doubt that Microsoft did their development of Active Directory without looking at the products it was intended to compete against. From a business standpoint, it makes sense to look at the market and make decisions based on what potential customers like about the leading product in the market and then to try to emulate those features that seem most important.
Microsoft already had a replication engine - the one used for replicating the address book in Exchange. That's what Active Directory is largely based on - so in that respect, it's also a knock-off of the Exchange address book data store, too. It uses many concepts that Exchange does - bridgehead servers, for example, allow for highly configurable (and thus also fairly managment-intensive configurations in larger environments) replication patterns. This is a concept Microsoft introduced originally in Exchange.
Microsoft also came from a master/slave replication model from the Domain architecture in NT3 and NT4; this particular type of background led to the introduction in AD (which is multimaster) of issues on Windows 2000 Server like the improper replication of group membership data when two DCs have a change introduced in the same replication cycle. In a master/slave design, all modifications enter at the master (the PDC in a Windows domain structure), so pushing the entire group membership from the PDC to the BDCs doesn't introduce the possibility that it might overwrite a list item that entered the domain at the BDC, because Microsoft prevented changes from entering through its "slave" domain controllers. With Active Directory, they originally kept that behaviour, but if you added a user to a group on DC "A" and another user to the same group on DC "B", the last change wins and the first change is discarded.
This behaviour was corrected in Windows Server 2003's version of Active Directory. A lot of things were fixed in "AD version 2". Some of the things they fixed are things Novell discovered almost 10 years ago with the first versions of NDS, however - so to that end, it's also fair to say that Microsoft didn't learn as much about directory services as they could have from Novell.
Actually, let's get our technical facts correct here.
AD is *somewhat* a rip-off of NDS - in that NDS predated Active Directory, and in fact it's what Microsoft itself has compared Active Directory to. Neither are proprietary implementations of the same open protocol, they're proprietary implementations of open standards.
eDirectory is based on the IETF X.500 directory model. No vendor implements all of X.500, but many of the ideas from X.500 find their ways into almost every directory server on the market.
Active Directory is also somewhat based on X.500, but also throws a lot of LDAP into the picture. It doesn't follow standard naming conventions (from the standpoint of object uniqueness is not per-container, but per domain).
Active Directory is young technology; it has problems with scalability partly because of the way some of the FSMO roles are implemented; for example, the use of a Global Catalog is something that inherently does not scale to very large implementations. Novell tried to do something like this years ago with their Catalog Services component for NDS8, and found the same thing - dredging the directory doesn't scale.
Active Directory lacks flexibility in the area of partitioning; the smallest unit of replication is the domain, and each DC can hold one and only one domain. Redesigning a forest takes a huge amount of effort, and on a large scale, Microsoft has not recommended using ADMT for that, but rather purchasing a third-party product in order to do this.
Monitoring is essential for any directory service - Microsoft offers MOM, which provides a very good function set, but at a hefty per-processor price.
eDirectory (a product Microsoft refuses to compare AD to, and rightfully so, because eDirectory is a very mature directory services product. All of Microsoft's competitive literature refers to NDS) includes iMonitor, which once you learn it (and yes, there is a learning curve) provides you with a great amount of detail on your eDirectory environment. And if you want to hook into a monitoring product, eDirectory is SNMP enabled.
> alright, so it was based on DOS, but for all intensive purposes,
<sigh>
NetWare uses DOS as a bootstrap. Period. The engineers at Novell who developed the loader mechanism back in the NetWare 3 days (NetWare 2.15 didn't use DOS as a bootstrap, though you could run non-dedicated mode and have a second "session" that ran DOS so the machine could be used as a workstation as well) decided that since DOS already gets a system started up, there was no need to reinvent the wheel.
SERVER.EXE loads from DOS; the NetWare kernel takes over, and DOS is left there for real-mode access to the floppy drive (and CD-ROM drive IFF you loaded the CD-ROM driver stuff in DOS before loading SERVER.EXE - this was common for installations back before access to CD-ROM drives were standardized and a lot of the drives used funky proprietary cards that needed special drivers rather than a standard, universal IDE or SCSI interface). Once the NetWare kernel takes over, DOS is not necessary; the fact that there has been a REMOVE DOS command on NetWare demonstrates this (though this has been removed from NetWare 6.5 and OES/NetWare and may even have been removed from NetWare 6; it was there to increase the memory pool in earlier versions because memory was so expensive in the past; now with memory as cheap as it is, there's no need to conserve that extra couple hundred K that DOS uses).
Nothing personal here, I just get tired of people making uninformed assertions like this - and there are several people here who have incorrectly made this comment because they assumed they knew how it worked rather than learning how it worked. NetWare IS NOT a DOS application, but lots of people believe very firmly it is. The NetWare *loader* is a DOS application.
It's interesting that their security improvement isn't the final solution, but there are solutions like that (implementations of Mandatory Access Controls) in Linux that are just so much better than the half-hearted security crap Microsoft puts into their operating systems.
Eye candy - yeah, it's coming to GNOME, not 2.14, but it is coming along. I don't see eye candy as a compelling reason to upgrade my OS - eye candy sucks the life out of the machine by wasting CPU cycles. Computer speeds are now over 500 times faster (in terms of CPU speed alone) than they were 10 years ago, yet it takes me longer to do things I could do on a computer 10 years ago because of all of the totally wasted time with things like Clippy. Application code is more bloated, OS kernel code is more bloated, everything's just more bloated. Bloat makes code slow. Run lots of bloated code on a system and you get the effective performance of a 4.77 MHz IBM PC.
But I'm sure that there are people in various OSS project teams who are watching what Microsoft's doing. It's hard to compete with them and not notice what they're doing.
Does this mean we're going to see Bill Gates on the deck of an aircraft carrier in full flight gear in front of a banner that reads "Mission Accomplished"?
If so, can we deploy that carrier to a forward operating area AS SOON AS POSSIBLE?
I can see something like this being used for user interface design - judging the reactions of users to certain interface decisions (if they could measure frustration, that would be a GREAT thing), but to reach a point where software requires that the user press CTRL+ALT+SHIFT+F12 while they're no more than 30% frustrated seems like a bad idea...Especially if the required keystrokes are not documented or the software reacts differently if they're more than 30% frustrated.
Just so my computer "knows" when I'm about to get pissed off at it, I'm going to spend 5 minutes attaching electrodes to myself so the computer can "behave" properly because it knows when I'm about to strap high explosives to it and set it off out in the desert. Having to type while wearing gloves is enough in and of itself to piss me off.
How about this instead - software and hardware developers develop software and hardware that responds rationally and logically so users don't get pissed off at the machine? The last thing I need is software that only works properly when I'm about to throw the keyboard across the room.
It probably would've made a difference to Paul Allen and his zillions of dollars, which was the topic of discussion to which I was referring.
If Kildall had taken to producing an OS for the PC, MicroSoft may never have had the chance to produce BASIC for it, and those who made their millions/billions may not have been quite so successful.
Well, I don't know that I'd call it accidental, but there was a rather significant luck factor involved; if Gary Kildall had pursued the opportunity (and there are several stories about why he didn't - ranging from opting to fly his plane instead of meet with IBM to refusing to sign an NDA; according to Gordon Eubanks, Kildall just wasn't interested in porting CP/M to the 8088 processor). If Seattle Computer Products hadn't sold QDOS to MicroSoft, things also would have been pretty different.
Seriously, though, when are the recording companies going to come to their senses over this - that DRM promotes piracy?
A friend of mine was working on a DVD slideshow of some trip photos and needed a musical backdrop; he chose a part of the Grand Canyon Suite and went to the trouble to legally acquire it through a download. Turns out he can't use it because of the DRM attached to the file.
His next step? Limewire, because he can get a file he can actuallly use for what he legally acquired the music for. DRM has taught him that if he goes to the trouble of legally acquiring music, he'll be punished for it, so he's better off downloading it through a P2P network.
DRM that prevents fair use (under which his usage falls) is NOT a deterrant to piracy - it encourages it.
DRM that restricts a choice of OS or playback device is NOT a deterrant to piracy - it encourages it.
I don't download music myself and haven't purchased a CD (even used) for about 5 years because of this nonsense. RIAA, if you want me to pay for music, I'll be happy to - as long as I can listen to my purchases on my iPod, on my Linux systems (as I don't do Windows here) without having to screw around at all. Most of your customers are trustworthy; don't punish the majority for the actions of a minority group.
In the end, you punish yourselves by making it difficult to consume your content. We'll either go somewhere else to get your content or we'll decide your content isn't worth acquiring. In my case, it's the latter - because let's face it, most of the crap that comes out of the recording industry is just that - crap.
All is a pretty strong word. It kinda makes that sentence complete horse shit.
I was thinking that same thing. I would say something like "all poorly-designed applications" or "all poorly-implemented solutions".
The only password on the last network I operated that never changed was an administrative account; that was set to a randomly generated password that was some 128 characters long (yes, there are actually systems out there that don't truncate passwords to a stupid length), printed out and locked in a safe somewhere. I was the one who generated it, and I couldn't tell you what it was.
In fact, come to think, that one did change regularly; about every 6 months - so I guess it's not fair to say it never changed. Yes, it was frequently a pain in the ass when someone left the company who knew the accounts used for backups, but those were changed on a semi-regular basis as well. "All" is a pretty strong word, but so is "never".
Sure it makes a difference. If you act professionally, it'll reflect on you in a positive manner. If you act unprofessionally, it'll likely haunt you forever.
I was involved in a fairly large project in my last job, so I offered a month as I recall. When I left my first position in the new company for another area, I hand-selected and trained my replacement. Handling that professionally saved me during a RIF that happened recently, as the first department asked me to come back.
Just remember that you have no control over how other people react to your decisions.
When I left my last job, I gave my notice and then talked to the director of data security and asked him how he wanted to handle transitioning my authority around. I told him straight up that my reputation is too important to me to leave privileged accounts behind, and that I would appreciate having the opportunity to disable my own access so I would be sure it was done properly. I didn't want something to happen and then for the company to think it was me because I'd recently left and had all sorts of authority on the systems.
My boss had already known of my feelings about that sort of thing, because we had talked about it in the past when others had left. He was fully aware of the conversation I had with the director of data security, and he was cool with it. He knew me well enough to know that I took my responsibilities seriously and wasn't going to do something that would bite me in the ass down the road.
I've seen that sort of thing happen; when I was in college, we had a guy who said he wanted to learn, so we gave him administrative access on the systems. He never showed up, and as inexperienced as we were, we didn't revoke his access. He went in and changed all of the passwords and locked out all of the administrative accounts after deleting his own account. He left a trail so blindingly clear that when the US Air Force called to do a security background check on him, they were informed about it (though not by me - but I was in the room when the call came in). The last I heard (and this was many years ago, so his circumstances may have changed), he was finishing up a 6 year ROTC tour of duty but unable to get a security clearance. Do you know how many jobs there are in the US Air Force involving computer science degrees that don't require a security clearance? Not many....
My boss understood that having seen someone screw their career over (former boss was ex-Navy, and had a top secret clearance) because they decided to act stupid with their authority meant that I wasn't about to do the same. I've always assumed that when it comes to IT systems, someone's watching me and I may not know how they're watching me, so I just don't screw around with the authority.
Being a systems administrator means that you have to be trustworthy - and trusted by your management. I've always said that if management doesn't trust a systems administrator (and if they don't for a good reason), then the systems administrator shouldn't be administering their systems. The fact that there is a lot of very sensitive corporate data accessible to someone with those types of rights means that you have to trust that they're not going to abuse their authority. That doesn't mean that you don't put auditing systems in place to audit access to sensitive data, but in most companies, the ones putting those systems in place are the system administrators, so they know the ins and outs of those systems - including how and where to disable them.
Of course, you might notice that my question isn't "what is the problem with using cell phones on airplanes" but "why don't you bust or confirm this myth?". I wasn't asking Adam and Jamie or the masses at/. for a lesson in EMI and radio transmissions - which is something I am already quite familiar with.
They are reluctant to touch the myth, and I am asking why. This is in fact a completely different question.
I went to school to be an aeronautical engineer, and am a licensed radio operator. I do actually know something about the subject.
All the same, I thank you for the interesting link.
I imagine that this isn't that uncommon a practice. Retagging items is a real pain, part of the reason many stores have abandoned price labels on the merchandise, but instead use shelf tags that are easier to change (for one thing, there's only one tag) and a SKU or UPC tag is used to correlate the item to the shelf tag. CompUSA does things this way, actually.
This makes it much more difficult to foll the system, especially with the self-destructive tags they tend to use for these things; you try to peel one off of one package, and you get about 15 tiny pieces of paper. Very difficult to make it look like a real tag without raising suspicions in the staff (assuming they're paying attention).
That's typically how it works here as well, but usually customers aren't honest enough to point out the mistake either. I know we probably really confused them just by pointing the problem out. Since the price was marked correctly but was just in the system wrong, I would've expected a note to be taken or something like that - it's what I would've done in the cashier's place.
That was how we treated it in a software store I worked in (and I also suffered retail burn out there - started part time and finished as part of the store's management team, *still* part-time).
We caught all sorts of things - tag swapping, shoplifting, even had some sort of "professional" shoplifter come in with a drop box kit designed for shoplifting - had him arrested. But mostly it was vigilence on the part of staff that kept us from being ripped off. If something rung up at the wrong price, we'd verify it - always. Caught a few wrong tags, and it was always a full set of boxes mismarked, so we'd ring it up as the tag said. Never had a bad experience with a real customer (as opposed to someone trying to steal from us).
Several years ago, as we were getting ready to go on vacation to Europe, we purchased a set of inexpensive suitcases to use for the trip. List price was $49.99, and it was marked as such on the tag. I would note that we did not screw with the tag in any way; we expected to pay $50 + tax for the set of two bags.
We checked out with those and several other items, and our total bill was under $30. As we walked out, we realised they'd made a mistake, and went back. The cashier looked at the tag, saw the $49.99 price on it, rescanned it, and it rang up at 4.99. She said "Well, looks like you got a good deal" and sent us on our way. We shoud've gone and purchased the other set as well, because now the first set (which has probably over 150,000 miles on it) has disintegrated, and we need to purchase another set.
The point here is that low-price retail stores need to treat their employees well enough that they care when someone points out a mistake like this. The girl at the checkout couldn't be bothered to correct the mistake, even though we were surprisingly honest about the store's mistake and offered them the chance to correct it. That's what you get when you hire minimum-wage workers who get no benefits - they couldn't care less whether the company loses money because of something like this.
The "Common Admin" these days tends to not understand how systems work. Sad, but true.
I would think that the important thing would be to raise the level of knowledge of the common admin, rather than to dumb down the technology to the point that it looks like Windows. Why is it that we expect our sysadmins to be unable to cope with decent technology?
That doesn't mean intentionally making the technology difficult to use. It means expecting that the masses sysadmins out there actually understand how to implement technology solutions and for them to understand the limits of those solutions.
Over the years, I've seen far, far too many sysadmins who - for example - in wanting to find a list of expired system accounts in a system with > 5,000 users, printed the list of users (and all attribute data) out in order to go through the list by hand to find the expired accounts. The printout was over 3,000 pages long (we stored a lot of data in the directory) and tied up a major printer on a floor of our building for an entire afternoon.
I laughed at the time, but this type of thinking seems to be considered almost normal by businesses. They say they're interested in ROI and TCO, but then hire idiots who don't know how to build a proper query for data - which certainly lowers their ROI and increases their TCO.
Bottom line - I don't think a product like this should aim at the common admin - because the "common" admin is an idiot. In order to administer systems properly, you should at least have a rudimentary knowledge of how to build a query, how to automate a process through scripting, and how to effectively implement security policies.
Slashdot Mirror
That depends on what you are intending to do with the directory. I have seen many companies who have well over 100,000 objects per container when they were designing (a) an external-facing directory, or (b) a very large identity vault for use with Novell Identity Manager. I probably wouldn't design a tree with this many objects in a single container that was partitioned to replicate over any type of WAN, but if all replicas are on the same high-speed backbone, this type of design isn't a problem.
eDirectory 8.7 can handle this type of scalability without breaking a sweat - as long as the hardware and network are (a) up to the task, and (b) configured correctly.
I think we're both "suffering" (not really the right word here, but I can't think of one that fits better here) from the same thing - being tired of uneducated points of view (no, I'm not saying yours is - I've reread the comments and - mea culpa - I misread the direction of the discussion). We both seem to share the same intolerance for ignorance.
My bad - please accept my apologies.
While I am a Novell die-hard (I in fact work for Novell), I have extensive experience with Active Directory, particularly in large scale designs and deployments. I also have personally met with and discussed Active Directory with Microsoft's product management and engineering managers, and a good friend of mine was in charge of the team that instrumented Active Directory for WMI (which is how Active Directory is monitored by MOM). Incidentally, that person used to work for Novell.
Simply put, I do not come from a position of ignorance on either product, but rather from an in-depth knowledge gained through detailed discussions with the people who have worked on the design of both products. My comment was neither emotional nor factless; it was based on my experience and discussions with people who know.
First off, NDS is an old Novell product; the current product is called eDirectory. So let's start by debating the proper products here. This is a myth that Microsoft continues to propagate even today with their competitive analysis; they refuse to compare to eDirectory because they know that in a feature-by-feature comparison, they lose. They prefer to compare to a product that had limitations of around 5000 objects per container, rather than one that supports millions of objects per container without breaking a sweat.
Coming back to the point of whether AD is a knock-off of NDS or eDirectory, though. It would be fair to say that one product released after another product that competes in the same space is going to incorporate design decisions that make the products comparable. I seriously doubt that Microsoft did their development of Active Directory without looking at the products it was intended to compete against. From a business standpoint, it makes sense to look at the market and make decisions based on what potential customers like about the leading product in the market and then to try to emulate those features that seem most important.
Microsoft already had a replication engine - the one used for replicating the address book in Exchange. That's what Active Directory is largely based on - so in that respect, it's also a knock-off of the Exchange address book data store, too. It uses many concepts that Exchange does - bridgehead servers, for example, allow for highly configurable (and thus also fairly managment-intensive configurations in larger environments) replication patterns. This is a concept Microsoft introduced originally in Exchange.
Microsoft also came from a master/slave replication model from the Domain architecture in NT3 and NT4; this particular type of background led to the introduction in AD (which is multimaster) of issues on Windows 2000 Server like the improper replication of group membership data when two DCs have a change introduced in the same replication cycle. In a master/slave design, all modifications enter at the master (the PDC in a Windows domain structure), so pushing the entire group membership from the PDC to the BDCs doesn't introduce the possibility that it might overwrite a list item that entered the domain at the BDC, because Microsoft prevented changes from entering through its "slave" domain controllers. With Active Directory, they originally kept that behaviour, but if you added a user to a group on DC "A" and another user to the same group on DC "B", the last change wins and the first change is discarded.
This behaviour was corrected in Windows Server 2003's version of Active Directory. A lot of things were fixed in "AD version 2". Some of the things they fixed are things Novell discovered almost 10 years ago with the first versions of NDS, however - so to that end, it's also fair to say that Microsoft didn't learn as much about directory services as they could have from Novell.
Actually, let's get our technical facts correct here.
AD is *somewhat* a rip-off of NDS - in that NDS predated Active Directory, and in fact it's what Microsoft itself has compared Active Directory to. Neither are proprietary implementations of the same open protocol, they're proprietary implementations of open standards.
eDirectory is based on the IETF X.500 directory model. No vendor implements all of X.500, but many of the ideas from X.500 find their ways into almost every directory server on the market.
Active Directory is also somewhat based on X.500, but also throws a lot of LDAP into the picture. It doesn't follow standard naming conventions (from the standpoint of object uniqueness is not per-container, but per domain).
Active Directory is young technology; it has problems with scalability partly because of the way some of the FSMO roles are implemented; for example, the use of a Global Catalog is something that inherently does not scale to very large implementations. Novell tried to do something like this years ago with their Catalog Services component for NDS8, and found the same thing - dredging the directory doesn't scale.
Active Directory lacks flexibility in the area of partitioning; the smallest unit of replication is the domain, and each DC can hold one and only one domain. Redesigning a forest takes a huge amount of effort, and on a large scale, Microsoft has not recommended using ADMT for that, but rather purchasing a third-party product in order to do this.
Monitoring is essential for any directory service - Microsoft offers MOM, which provides a very good function set, but at a hefty per-processor price.
eDirectory (a product Microsoft refuses to compare AD to, and rightfully so, because eDirectory is a very mature directory services product. All of Microsoft's competitive literature refers to NDS) includes iMonitor, which once you learn it (and yes, there is a learning curve) provides you with a great amount of detail on your eDirectory environment. And if you want to hook into a monitoring product, eDirectory is SNMP enabled.
> alright, so it was based on DOS, but for all intensive purposes,
<sigh>
NetWare uses DOS as a bootstrap. Period. The engineers at Novell who developed the loader mechanism back in the NetWare 3 days (NetWare 2.15 didn't use DOS as a bootstrap, though you could run non-dedicated mode and have a second "session" that ran DOS so the machine could be used as a workstation as well) decided that since DOS already gets a system started up, there was no need to reinvent the wheel.
SERVER.EXE loads from DOS; the NetWare kernel takes over, and DOS is left there for real-mode access to the floppy drive (and CD-ROM drive IFF you loaded the CD-ROM driver stuff in DOS before loading SERVER.EXE - this was common for installations back before access to CD-ROM drives were standardized and a lot of the drives used funky proprietary cards that needed special drivers rather than a standard, universal IDE or SCSI interface). Once the NetWare kernel takes over, DOS is not necessary; the fact that there has been a REMOVE DOS command on NetWare demonstrates this (though this has been removed from NetWare 6.5 and OES/NetWare and may even have been removed from NetWare 6; it was there to increase the memory pool in earlier versions because memory was so expensive in the past; now with memory as cheap as it is, there's no need to conserve that extra couple hundred K that DOS uses).
Nothing personal here, I just get tired of people making uninformed assertions like this - and there are several people here who have incorrectly made this comment because they assumed they knew how it worked rather than learning how it worked. NetWare IS NOT a DOS application, but lots of people believe very firmly it is. The NetWare *loader* is a DOS application.
It's interesting that their security improvement isn't the final solution, but there are solutions like that (implementations of Mandatory Access Controls) in Linux that are just so much better than the half-hearted security crap Microsoft puts into their operating systems.
Eye candy - yeah, it's coming to GNOME, not 2.14, but it is coming along. I don't see eye candy as a compelling reason to upgrade my OS - eye candy sucks the life out of the machine by wasting CPU cycles. Computer speeds are now over 500 times faster (in terms of CPU speed alone) than they were 10 years ago, yet it takes me longer to do things I could do on a computer 10 years ago because of all of the totally wasted time with things like Clippy. Application code is more bloated, OS kernel code is more bloated, everything's just more bloated. Bloat makes code slow. Run lots of bloated code on a system and you get the effective performance of a 4.77 MHz IBM PC.
But I'm sure that there are people in various OSS project teams who are watching what Microsoft's doing. It's hard to compete with them and not notice what they're doing.
How many times in the past has Microsoft made promises to fix the security issues in Windows?
Let's all say the old saying together:
Fool me once, shame on you. Fool me twice, shame on me.
Does this mean we're going to see Bill Gates on the deck of an aircraft carrier in full flight gear in front of a banner that reads "Mission Accomplished"?
If so, can we deploy that carrier to a forward operating area AS SOON AS POSSIBLE?
LOL....
I can see something like this being used for user interface design - judging the reactions of users to certain interface decisions (if they could measure frustration, that would be a GREAT thing), but to reach a point where software requires that the user press CTRL+ALT+SHIFT+F12 while they're no more than 30% frustrated seems like a bad idea...Especially if the required keystrokes are not documented or the software reacts differently if they're more than 30% frustrated.
Just so my computer "knows" when I'm about to get pissed off at it, I'm going to spend 5 minutes attaching electrodes to myself so the computer can "behave" properly because it knows when I'm about to strap high explosives to it and set it off out in the desert. Having to type while wearing gloves is enough in and of itself to piss me off.
How about this instead - software and hardware developers develop software and hardware that responds rationally and logically so users don't get pissed off at the machine? The last thing I need is software that only works properly when I'm about to throw the keyboard across the room.
Oh, wait, that happens already.
It probably would've made a difference to Paul Allen and his zillions of dollars, which was the topic of discussion to which I was referring.
If Kildall had taken to producing an OS for the PC, MicroSoft may never have had the chance to produce BASIC for it, and those who made their millions/billions may not have been quite so successful.
Well, I don't know that I'd call it accidental, but there was a rather significant luck factor involved; if Gary Kildall had pursued the opportunity (and there are several stories about why he didn't - ranging from opting to fly his plane instead of meet with IBM to refusing to sign an NDA; according to Gordon Eubanks, Kildall just wasn't interested in porting CP/M to the 8088 processor). If Seattle Computer Products hadn't sold QDOS to MicroSoft, things also would have been pretty different.
I thought this was something we already knew...?
Seriously, though, when are the recording companies going to come to their senses over this - that DRM promotes piracy?
A friend of mine was working on a DVD slideshow of some trip photos and needed a musical backdrop; he chose a part of the Grand Canyon Suite and went to the trouble to legally acquire it through a download. Turns out he can't use it because of the DRM attached to the file.
His next step? Limewire, because he can get a file he can actuallly use for what he legally acquired the music for. DRM has taught him that if he goes to the trouble of legally acquiring music, he'll be punished for it, so he's better off downloading it through a P2P network.
DRM that prevents fair use (under which his usage falls) is NOT a deterrant to piracy - it encourages it.
DRM that restricts a choice of OS or playback device is NOT a deterrant to piracy - it encourages it.
I don't download music myself and haven't purchased a CD (even used) for about 5 years because of this nonsense. RIAA, if you want me to pay for music, I'll be happy to - as long as I can listen to my purchases on my iPod, on my Linux systems (as I don't do Windows here) without having to screw around at all. Most of your customers are trustworthy; don't punish the majority for the actions of a minority group.
In the end, you punish yourselves by making it difficult to consume your content. We'll either go somewhere else to get your content or we'll decide your content isn't worth acquiring. In my case, it's the latter - because let's face it, most of the crap that comes out of the recording industry is just that - crap.
Ah, I see - yes.
It's funny how two people can say the same thing differently and not realize they're saying the same thing for a bit.
All is a pretty strong word. It kinda makes that sentence complete horse shit.
I was thinking that same thing. I would say something like "all poorly-designed applications" or "all poorly-implemented solutions".
The only password on the last network I operated that never changed was an administrative account; that was set to a randomly generated password that was some 128 characters long (yes, there are actually systems out there that don't truncate passwords to a stupid length), printed out and locked in a safe somewhere. I was the one who generated it, and I couldn't tell you what it was.
In fact, come to think, that one did change regularly; about every 6 months - so I guess it's not fair to say it never changed. Yes, it was frequently a pain in the ass when someone left the company who knew the accounts used for backups, but those were changed on a semi-regular basis as well. "All" is a pretty strong word, but so is "never".
Sure it makes a difference. If you act professionally, it'll reflect on you in a positive manner. If you act unprofessionally, it'll likely haunt you forever.
I was involved in a fairly large project in my last job, so I offered a month as I recall. When I left my first position in the new company for another area, I hand-selected and trained my replacement. Handling that professionally saved me during a RIF that happened recently, as the first department asked me to come back.
Burning bridges in IT is a very, very bad idea.
To your boss, as always.
Just remember that you have no control over how other people react to your decisions.
When I left my last job, I gave my notice and then talked to the director of data security and asked him how he wanted to handle transitioning my authority around. I told him straight up that my reputation is too important to me to leave privileged accounts behind, and that I would appreciate having the opportunity to disable my own access so I would be sure it was done properly. I didn't want something to happen and then for the company to think it was me because I'd recently left and had all sorts of authority on the systems.
My boss had already known of my feelings about that sort of thing, because we had talked about it in the past when others had left. He was fully aware of the conversation I had with the director of data security, and he was cool with it. He knew me well enough to know that I took my responsibilities seriously and wasn't going to do something that would bite me in the ass down the road.
I've seen that sort of thing happen; when I was in college, we had a guy who said he wanted to learn, so we gave him administrative access on the systems. He never showed up, and as inexperienced as we were, we didn't revoke his access. He went in and changed all of the passwords and locked out all of the administrative accounts after deleting his own account. He left a trail so blindingly clear that when the US Air Force called to do a security background check on him, they were informed about it (though not by me - but I was in the room when the call came in). The last I heard (and this was many years ago, so his circumstances may have changed), he was finishing up a 6 year ROTC tour of duty but unable to get a security clearance. Do you know how many jobs there are in the US Air Force involving computer science degrees that don't require a security clearance? Not many....
My boss understood that having seen someone screw their career over (former boss was ex-Navy, and had a top secret clearance) because they decided to act stupid with their authority meant that I wasn't about to do the same. I've always assumed that when it comes to IT systems, someone's watching me and I may not know how they're watching me, so I just don't screw around with the authority.
Being a systems administrator means that you have to be trustworthy - and trusted by your management. I've always said that if management doesn't trust a systems administrator (and if they don't for a good reason), then the systems administrator shouldn't be administering their systems. The fact that there is a lot of very sensitive corporate data accessible to someone with those types of rights means that you have to trust that they're not going to abuse their authority. That doesn't mean that you don't put auditing systems in place to audit access to sensitive data, but in most companies, the ones putting those systems in place are the system administrators, so they know the ins and outs of those systems - including how and where to disable them.
Of course, you might notice that my question isn't "what is the problem with using cell phones on airplanes" but "why don't you bust or confirm this myth?". I wasn't asking Adam and Jamie or the masses at /. for a lesson in EMI and radio transmissions - which is something I am already quite familiar with.
They are reluctant to touch the myth, and I am asking why. This is in fact a completely different question.
I went to school to be an aeronautical engineer, and am a licensed radio operator. I do actually know something about the subject.
All the same, I thank you for the interesting link.
I imagine that this isn't that uncommon a practice. Retagging items is a real pain, part of the reason many stores have abandoned price labels on the merchandise, but instead use shelf tags that are easier to change (for one thing, there's only one tag) and a SKU or UPC tag is used to correlate the item to the shelf tag. CompUSA does things this way, actually.
This makes it much more difficult to foll the system, especially with the self-destructive tags they tend to use for these things; you try to peel one off of one package, and you get about 15 tiny pieces of paper. Very difficult to make it look like a real tag without raising suspicions in the staff (assuming they're paying attention).
That's typically how it works here as well, but usually customers aren't honest enough to point out the mistake either. I know we probably really confused them just by pointing the problem out. Since the price was marked correctly but was just in the system wrong, I would've expected a note to be taken or something like that - it's what I would've done in the cashier's place.
That was how we treated it in a software store I worked in (and I also suffered retail burn out there - started part time and finished as part of the store's management team, *still* part-time).
We caught all sorts of things - tag swapping, shoplifting, even had some sort of "professional" shoplifter come in with a drop box kit designed for shoplifting - had him arrested. But mostly it was vigilence on the part of staff that kept us from being ripped off. If something rung up at the wrong price, we'd verify it - always. Caught a few wrong tags, and it was always a full set of boxes mismarked, so we'd ring it up as the tag said. Never had a bad experience with a real customer (as opposed to someone trying to steal from us).
Several years ago, as we were getting ready to go on vacation to Europe, we purchased a set of inexpensive suitcases to use for the trip. List price was $49.99, and it was marked as such on the tag. I would note that we did not screw with the tag in any way; we expected to pay $50 + tax for the set of two bags.
We checked out with those and several other items, and our total bill was under $30. As we walked out, we realised they'd made a mistake, and went back. The cashier looked at the tag, saw the $49.99 price on it, rescanned it, and it rang up at 4.99. She said "Well, looks like you got a good deal" and sent us on our way. We shoud've gone and purchased the other set as well, because now the first set (which has probably over 150,000 miles on it) has disintegrated, and we need to purchase another set.
The point here is that low-price retail stores need to treat their employees well enough that they care when someone points out a mistake like this. The girl at the checkout couldn't be bothered to correct the mistake, even though we were surprisingly honest about the store's mistake and offered them the chance to correct it. That's what you get when you hire minimum-wage workers who get no benefits - they couldn't care less whether the company loses money because of something like this.
The "Common Admin" these days tends to not understand how systems work. Sad, but true.
I would think that the important thing would be to raise the level of knowledge of the common admin, rather than to dumb down the technology to the point that it looks like Windows. Why is it that we expect our sysadmins to be unable to cope with decent technology?
That doesn't mean intentionally making the technology difficult to use. It means expecting that the masses sysadmins out there actually understand how to implement technology solutions and for them to understand the limits of those solutions.
Over the years, I've seen far, far too many sysadmins who - for example - in wanting to find a list of expired system accounts in a system with > 5,000 users, printed the list of users (and all attribute data) out in order to go through the list by hand to find the expired accounts. The printout was over 3,000 pages long (we stored a lot of data in the directory) and tied up a major printer on a floor of our building for an entire afternoon.
I laughed at the time, but this type of thinking seems to be considered almost normal by businesses. They say they're interested in ROI and TCO, but then hire idiots who don't know how to build a proper query for data - which certainly lowers their ROI and increases their TCO.
Bottom line - I don't think a product like this should aim at the common admin - because the "common" admin is an idiot. In order to administer systems properly, you should at least have a rudimentary knowledge of how to build a query, how to automate a process through scripting, and how to effectively implement security policies.
Use standard HTML "a href" code.