Maryland deregulated its power a few years back. They insisted that "market forces" would allow consumers to "choose" their electrical power here in MD, and Baltimore in general.
Guess what? It didn't happen. Guess what happened? Prices went far up as a result of this "deregulation".
Guess what else? The deregulation was pushed by Enron....
It was given to them by local governments. At least, around here it was. Comcast had an essential monopoly in Baltimore county for many, many years. It made it impossible for any competing ISP to step in and grab market in this county.
Guess what? The surrounding ISPs/cable companies went out of business because of this.
Even if the countries allowed American workers to do something like that, it would be nearly impossible for us to do it financially.
Unlike them, where the cost of debts is a smaller portion of their paycheck (due to exchange rate), the reverse is true for American workers.
So you end up going to school here, go $40,000 into debt on student loans. Then move to India and that becomes a significant portion (if not moreso) of your paycheck.
While the above cost may be amazingly expensive in India, you could quickly pay all of that cost back by scoring a job in the United States. The average cost of a similar education in the US is sometimes as much as 10 times that, even higher if you attend a private university.
It's not that American workers are underskilled or underqualified, it's that the cost of entry into the same field of work is significantly higher than these foreign workers. The cost of something like a PhD is even much higher than a simple bachelor's degree.
And people wonder why you can't find "quality American workers".
Truecrypt allows you to do this by placing a hidden partition within an encrypted partition. You can also do this with encrypted files.
You create your "dummy" file/partition, add in some files, then create a secondary hidden volume inside of that. The only thing separating the two volumes is the password you place. There is no other way to identify the second volume.
Unfortunately this also means if you start mucking around with the primary volume you may in fact overwrite the secondary volume.
So the idea is that when they ask, you place the password in for the "dummy". This then decrypts the dummy to the full size of the encrypted file (of say, 30GB). They see a bunch of data that you otherwise might want to protect and they let you go on your way.
Just make sure the password is something you would use as a password or something that they could prove you would use as a password. If you're a seasoned IT pro chances are you're not using "gummibears" as your password. Choose something reasonable for you. Then you can deny the existence of a second password. Make it strong enough and they won't guess the second one guaranteed.
As was stated you can get around this by registering a domain name with international characters that appear to look like characters you would either find in a domain (or looks like the other counterpart).
Then you register that long domain with the international character and get an SSL certificate for that domain.
Viola. The end user sees the trusted padlock because it's a very valid certificate for the domain the user is visiting.
They did work with Vista. Vista Basic. They did not work with Vista Home Premium. Call it a little unclear on the manufacturer's front. Call it a little unclear on Microsoft's part. Whatever have you.
But you cannot discount Vista Basic as not being Vista just because it does not have Aero.
Incorrect. The AC is correct when he said that it signifies HDCP support.
If you found this on an analog monitor with no digital connection, chances are the vendor placed it there. You could probably report it to Microsoft if you wanted to go out of your way and they might mention something to the manufacturer.
You're quoting an e-mail from 6 years ago, and more importantly what he said may have been out of context. You don't know what he meant by "wasn't usable". He did not elaborate.
My question to you is what parts of Internet Explorer were "embedded into the kernel", and more importantly, what exploits and viruses/worms have access to the "kernel" of the operating system through IE.
I'm no Windows kernel expert, but if you are I'd love to learn some more.
Most of the problems I've seen with IE have more to do with users installing ActiveX applications rather than flat browser exploits. While browser exploits do exist and are important to guard against, a vast majority of problems that exist out there are user-initiated.
What worms or trojans hook into the kernel of the OS?
#1. Registry is fine. What about "library hell" and "dependency hell" that other operating systems have? or "conf hell"? There are many "hells" we can talk about that exist in all systems. It's the complex nature of how the applications work.
#2. Java is not embedded in modern browsers. You need to download an extra java client to run java applications. If you're talking about javascript, that is a different story.
#3. Viruses predate Microsoft's modern operating systems. First virus/worm: The Creeper virus was first detected on ARPANET, the forerunner of the Internet in the early 1970s.[3] Creeper was an experimental self-replicating program written by Bob Thomas at BBN in 1971.[4] Creeper used the ARPANET to infect DEC PDP-10 computers running the TENEX operating system. Creeper gained access via the ARPANET and copied itself to the remote system where the message, "I'm the creeper, catch me if you can!" was displayed. - Wikipedia.
It's nothing, it has nothing to do with anything Microsoft has or hasn't done. The OP is mentally handicapped, and even that might be giving him too much credit.
Drop the Creative card. That's not Windows' fault, it's Creative's shitty drivers and hardware support.
Creative being a dipshit has been well known since before the Windows XP days. The only thing good to come out of Creative has been the SB16, and that was 15 years ago.
Windows XP only supported certain revisions of the SBLive! cards, even though they were all branded and sold as the same card. Creative also did not have a valid sound driver out for Windows XP until October 26, 2001--1 day after Windows XP went retail. This, in spite of having the driver framework readily available to them for years (Windows 2000).
The same type of DRM in OSX is the same type of DRM support in Windows. It's required because vendors require it.
If there was no "DRM support" in Windows then you wouldn't have the ability to have DVD or Blu-ray playback.
This has nothing to do with Microsoft wanting to "lock down" your content, prevent you from sharing files, or anything of that nature. It has everything to do with supporting technology that is already in existence for home theater PC purposes.
My take on the situation is that this person is stupid. For one, there's nothing wrong with what's going on. There are plenty of analogies above that make similar points regarding car stereos and engines.
If you don't like what is offered, then don't pay for it.
Simple answer for Microsoft next time: Tell everyone "fuck you" and not offer the older at all with the exception of the volume market and business market. This is all some stupid, frivolous lawsuit like this is going to accomplish.
Let me straighten this out since you feel like being a shit.
I understand the concept of running applications with the least amount of privilege they need on the system to do their job. I understand this concept 100%. HOWEVER, the situation comes into play that even if you fire up an application as a "limited user", it still may be more system access than what the application requires. So in cases such as this, running as root versus "Admin user that has more access than any standard account" is not of much consequence. Particularly if this "admin user account" has access to "internal company data".
The reality is, who gives a damn if an application can wipe out your system install? While this creates a burden of time and effort if you haven't backed things up properly, it's not necessarily a huge security issue. Even if the application fires up a root kit, what's it matter? If it already has read privileges to possibly critical network data anyway, you've already lost.
No, the security issue comes in when you do something like "Launch Application as user that has access to $INTERNAL_COMPANY_FINANCE_DOCUMENTS".
I agree, Linux does not go far enough with security. In fact, the default in most installs is that everything has at the very least read access to everything else. And this is a serious problem, and in some cases even some applications have complained about changing this. (I've tried it with/etc).
But the above situation is just this: Generally speaking, I run applications with a reduced privilege. I, however, perform administrative tasks as root. And sure, while I'm firing up something like 'nano' as root (and why should I trust nano?), I'm going on the assumption that I'm trusting the distro developers to have done an okay job. If I needed more security than this or felt the information I was working with was so utterly critical that I couldn't do this, I would most certainly use the system differently.
Generally speaking, at this point this is where things such as Trusted Computing come into play, where you only can launch applications that have been signed and trusted to run, taking the guesswork out of having to comb through source files yourself to make sure an application is clean before you compile them.
But as I've stated, I don't need this level of security. I understand its purpose, but I'm not quite that paranoid.
I install applications as root using package managers, in the event that the application I run is not found in the distribution, I download it, configure it, build it, make runtime configuration settings, and then use built-in system functions to run the application as a lower privileged user (usually application name) with a shell set to/sbin/nologin.
From my experience companies give local admin rights to users to keep them from complaining (and to keep IT doing other, more important things).
This isn't directed to you, but to the people who may have a misunderstanding of how adding users in domains works:
In order to join a computer to a domain, you need to supply credentials of someone who can do this (normally, Domain Admin or higher is required).
This does not automatically make the added user Admin nor does it give Local Admin access to the box. That is, unless you put them in a group that does indeed have these rights.
Typically, Domain Admin, Enterprise Admin groups are added to a machine's Administrators group when it joins the domain.
I run as root, I don't get rooted. I don't let internet facing applications run as root, as once I finish configuring the system (if the package manager hasn't already done so), I create a user and use start-stop-daemon to launch the process as that user.
Problem solved.
There's nothing wrong with running as root, it's understanding how to do it. Don't run listening daemons as root and you're generally good to go.
Essentially, your idea is to keep users in the dark from understanding how their system security works. You aren't teaching users how to properly secure their system, just "avoid" this "root" thing.
The accounts are an Administrator account but within the context of UAC and Vista this simply means whether or not you're forced to enter a password to elevate.
That's the only difference. Otherwise the Administrator account by default on Vista is a limited account.
UAC was not a failure to enforce this. And there are plenty of linux applications that *require* root to be installed. In fact, many of these applications will run in whatever context of whatever user is logged in at the time of launching them. This isn't entirely different from how Windows handles the situation.
If anything, it's typically the distribution teams that go out of their way to ensure that when an application compiles it follows a convention (for example, Gentoo uses the user "apache" to start processes for apache while Ubuntu uses "www-data").
However, outside of a couple of applications that really complain, linux apps are more than happy on doing what you tell it to do--including running it as root.
Slashdot Mirror
Actually, I'll give you an example.
http://en.wikipedia.org/wiki/Maryland_Electric_Deregulation
Maryland deregulated its power a few years back. They insisted that "market forces" would allow consumers to "choose" their electrical power here in MD, and Baltimore in general.
Guess what? It didn't happen. Guess what happened? Prices went far up as a result of this "deregulation".
Guess what else? The deregulation was pushed by Enron....
It was given to them by local governments. At least, around here it was. Comcast had an essential monopoly in Baltimore county for many, many years. It made it impossible for any competing ISP to step in and grab market in this county.
Guess what? The surrounding ISPs/cable companies went out of business because of this.
voss:
Even if the countries allowed American workers to do something like that, it would be nearly impossible for us to do it financially.
Unlike them, where the cost of debts is a smaller portion of their paycheck (due to exchange rate), the reverse is true for American workers.
So you end up going to school here, go $40,000 into debt on student loans. Then move to India and that becomes a significant portion (if not moreso) of your paycheck.
The US could compete if the cost of getting an education here was much cheaper. The problem is--it isn't.
I have no problems with the foreign workers themselves. They, like us, are trying to make a good living. And they do a good job at that.
But they have a much lower cost of education. Doing a quick google search brings up the following URL on the education cost in India.
http://prayatna.typepad.com/education/2005/07/what_does_a_uni.html
While the above cost may be amazingly expensive in India, you could quickly pay all of that cost back by scoring a job in the United States. The average cost of a similar education in the US is sometimes as much as 10 times that, even higher if you attend a private university.
It's not that American workers are underskilled or underqualified, it's that the cost of entry into the same field of work is significantly higher than these foreign workers. The cost of something like a PhD is even much higher than a simple bachelor's degree.
And people wonder why you can't find "quality American workers".
Truecrypt allows you to do this by placing a hidden partition within an encrypted partition. You can also do this with encrypted files.
You create your "dummy" file/partition, add in some files, then create a secondary hidden volume inside of that. The only thing separating the two volumes is the password you place. There is no other way to identify the second volume.
Unfortunately this also means if you start mucking around with the primary volume you may in fact overwrite the secondary volume.
So the idea is that when they ask, you place the password in for the "dummy". This then decrypts the dummy to the full size of the encrypted file (of say, 30GB). They see a bunch of data that you otherwise might want to protect and they let you go on your way.
Just make sure the password is something you would use as a password or something that they could prove you would use as a password. If you're a seasoned IT pro chances are you're not using "gummibears" as your password. Choose something reasonable for you. Then you can deny the existence of a second password. Make it strong enough and they won't guess the second one guaranteed.
Not necessarily sir.
As was stated you can get around this by registering a domain name with international characters that appear to look like characters you would either find in a domain (or looks like the other counterpart).
Then you register that long domain with the international character and get an SSL certificate for that domain.
Viola. The end user sees the trusted padlock because it's a very valid certificate for the domain the user is visiting.
They did work with Vista. Vista Basic. They did not work with Vista Home Premium. Call it a little unclear on the manufacturer's front. Call it a little unclear on Microsoft's part. Whatever have you.
But you cannot discount Vista Basic as not being Vista just because it does not have Aero.
Incorrect. The AC is correct when he said that it signifies HDCP support.
If you found this on an analog monitor with no digital connection, chances are the vendor placed it there. You could probably report it to Microsoft if you wanted to go out of your way and they might mention something to the manufacturer.
You're quoting an e-mail from 6 years ago, and more importantly what he said may have been out of context. You don't know what he meant by "wasn't usable". He did not elaborate.
My question to you is what parts of Internet Explorer were "embedded into the kernel", and more importantly, what exploits and viruses/worms have access to the "kernel" of the operating system through IE.
I'm no Windows kernel expert, but if you are I'd love to learn some more.
Most of the problems I've seen with IE have more to do with users installing ActiveX applications rather than flat browser exploits. While browser exploits do exist and are important to guard against, a vast majority of problems that exist out there are user-initiated.
What worms or trojans hook into the kernel of the OS?
#1. Registry is fine. What about "library hell" and "dependency hell" that other operating systems have? or "conf hell"? There are many "hells" we can talk about that exist in all systems. It's the complex nature of how the applications work.
#2. Java is not embedded in modern browsers. You need to download an extra java client to run java applications. If you're talking about javascript, that is a different story.
#3. Viruses predate Microsoft's modern operating systems. First virus/worm: The Creeper virus was first detected on ARPANET, the forerunner of the Internet in the early 1970s.[3] Creeper was an experimental self-replicating program written by Bob Thomas at BBN in 1971.[4] Creeper used the ARPANET to infect DEC PDP-10 computers running the TENEX operating system. Creeper gained access via the ARPANET and copied itself to the remote system where the message, "I'm the creeper, catch me if you can!" was displayed. - Wikipedia.
It's nothing, it has nothing to do with anything Microsoft has or hasn't done. The OP is mentally handicapped, and even that might be giving him too much credit.
Drop the Creative card. That's not Windows' fault, it's Creative's shitty drivers and hardware support.
Creative being a dipshit has been well known since before the Windows XP days. The only thing good to come out of Creative has been the SB16, and that was 15 years ago.
Windows XP only supported certain revisions of the SBLive! cards, even though they were all branded and sold as the same card. Creative also did not have a valid sound driver out for Windows XP until October 26, 2001--1 day after Windows XP went retail. This, in spite of having the driver framework readily available to them for years (Windows 2000).
This isn't "evidence" of anything except the retarded brain of the OP. You sir, need to leave /. and go read some IT books.
The same type of DRM in OSX is the same type of DRM support in Windows. It's required because vendors require it.
If there was no "DRM support" in Windows then you wouldn't have the ability to have DVD or Blu-ray playback.
This has nothing to do with Microsoft wanting to "lock down" your content, prevent you from sharing files, or anything of that nature. It has everything to do with supporting technology that is already in existence for home theater PC purposes.
How is it a "bait and switch"?
A bait and switch means that they intended to sell XP with the PC but put Vista on there instead, that the consumer did not "get what they paid for."
That's incorrect. They paid for Vista, the sale was advertised as Vista, and that's what they got.
Just because there was no option for XP does not mean there was anything wrong done by Microsoft nor the retailers nor the OEMs.
This entire article is completely irrelevant to Linux, fyi.
My take on the situation is that this person is stupid. For one, there's nothing wrong with what's going on. There are plenty of analogies above that make similar points regarding car stereos and engines.
If you don't like what is offered, then don't pay for it.
Simple answer for Microsoft next time: Tell everyone "fuck you" and not offer the older at all with the exception of the volume market and business market. This is all some stupid, frivolous lawsuit like this is going to accomplish.
Okay,
/etc).
/sbin/nologin.
Let me straighten this out since you feel like being a shit.
I understand the concept of running applications with the least amount of privilege they need on the system to do their job. I understand this concept 100%. HOWEVER, the situation comes into play that even if you fire up an application as a "limited user", it still may be more system access than what the application requires. So in cases such as this, running as root versus "Admin user that has more access than any standard account" is not of much consequence. Particularly if this "admin user account" has access to "internal company data".
The reality is, who gives a damn if an application can wipe out your system install? While this creates a burden of time and effort if you haven't backed things up properly, it's not necessarily a huge security issue. Even if the application fires up a root kit, what's it matter? If it already has read privileges to possibly critical network data anyway, you've already lost.
No, the security issue comes in when you do something like "Launch Application as user that has access to $INTERNAL_COMPANY_FINANCE_DOCUMENTS".
I agree, Linux does not go far enough with security. In fact, the default in most installs is that everything has at the very least read access to everything else. And this is a serious problem, and in some cases even some applications have complained about changing this. (I've tried it with
But the above situation is just this: Generally speaking, I run applications with a reduced privilege. I, however, perform administrative tasks as root. And sure, while I'm firing up something like 'nano' as root (and why should I trust nano?), I'm going on the assumption that I'm trusting the distro developers to have done an okay job. If I needed more security than this or felt the information I was working with was so utterly critical that I couldn't do this, I would most certainly use the system differently.
Generally speaking, at this point this is where things such as Trusted Computing come into play, where you only can launch applications that have been signed and trusted to run, taking the guesswork out of having to comb through source files yourself to make sure an application is clean before you compile them.
But as I've stated, I don't need this level of security. I understand its purpose, but I'm not quite that paranoid.
I install applications as root using package managers, in the event that the application I run is not found in the distribution, I download it, configure it, build it, make runtime configuration settings, and then use built-in system functions to run the application as a lower privileged user (usually application name) with a shell set to
You completely did not even read my comment...
From my experience companies give local admin rights to users to keep them from complaining (and to keep IT doing other, more important things).
This isn't directed to you, but to the people who may have a misunderstanding of how adding users in domains works:
In order to join a computer to a domain, you need to supply credentials of someone who can do this (normally, Domain Admin or higher is required).
This does not automatically make the added user Admin nor does it give Local Admin access to the box. That is, unless you put them in a group that does indeed have these rights.
Typically, Domain Admin, Enterprise Admin groups are added to a machine's Administrators group when it joins the domain.
I run as root, I don't get rooted. I don't let internet facing applications run as root, as once I finish configuring the system (if the package manager hasn't already done so), I create a user and use start-stop-daemon to launch the process as that user.
Problem solved.
There's nothing wrong with running as root, it's understanding how to do it. Don't run listening daemons as root and you're generally good to go.
Essentially, your idea is to keep users in the dark from understanding how their system security works. You aren't teaching users how to properly secure their system, just "avoid" this "root" thing.
The accounts are an Administrator account but within the context of UAC and Vista this simply means whether or not you're forced to enter a password to elevate.
That's the only difference. Otherwise the Administrator account by default on Vista is a limited account.
UAC was not a failure to enforce this. And there are plenty of linux applications that *require* root to be installed. In fact, many of these applications will run in whatever context of whatever user is logged in at the time of launching them. This isn't entirely different from how Windows handles the situation.
If anything, it's typically the distribution teams that go out of their way to ensure that when an application compiles it follows a convention (for example, Gentoo uses the user "apache" to start processes for apache while Ubuntu uses "www-data").
However, outside of a couple of applications that really complain, linux apps are more than happy on doing what you tell it to do--including running it as root.
That's what UAC is for. It's there, applications can take advantage of it. IE takes advantage of it. Even Chrome takes advantage of it.
Most software developers are freakin' lazy.
Uhm...
Microsoft has had Windows setup to not require administrative privileges for many, many, many years.
I blame software developers who abused the fact that people did.