It is cheaper in the long run just to make the switch to x64 than it is trying to make a hack work, especially a bad hack like over 4Gb support in an OS released in 2001
The hack is PAE, and is HW-related. 32-bit has a 4GB limitation/app which will NEVER be changed (unless recompiling to 64-bit). PAE allows and OS to use more than 4GB, but in client XP (Home/Professional) it was limited by SW. Pentium Pro (1995) was the 1st processor with PAE (36-bit address lanes). Windows 2000 already had a PAE implementation. From http://en.wikipedia.org/wiki/Windows_2000:
Windows 2000 Advanced Server is a variant of Windows 2000 Server operating system designed for medium-to-large businesses. It offers clustering infrastructure for high availability and scalability of applications and services, including main memory support of up to 8 gigabytes (GB) on Physical Address Extension (PAE) systems and the ability to do 8-way SMP.
WRONG!! WRONG!! WRONG!! You are confusing virtual (app) memory and physical memory. Virtual memory is ALWAYS limited to 4GB (with 2/2GB or 3/1GB split of user/kernel) on 32-bit, PAE or not, Workstation or Server. PAE allows for more than 4GB PHYSICAL memory. That means you could have 2 3GB apps running all in RAM (no swap) in 6+GB RAM. For ONE app to use more than 4GB, you NEED 64-bit. Each application page (usually 4K) is mapped to physical space, whether it's RAM or swap (when idle of course). The PAE allows you to map a page on more than 4GB RAM. This is done entirely by OS. The problem is that drivers need to know the physical address, because that is what HW devices can access. Some drivers are poorly implemented and fail to do this (like giving a 32-bit address when they sould give 36-bit to the HW). For a server, the company usually has an IT department that can get certified HW (not off-the-shelf cheap HW) and they usually test the server before deploying. So any driver issue can be corrected (either change the HW or resolve the driver issue) before deployment. So MS did not want to get calls of data corruption and limited PAE on client windows. My problem (and the article's author's) is that WE (tech-savy computer users) cannot activate it afterwards. PS: PAE was implemented since Pentium Pro. As I recall it already had 36-lines for adresses (that is 64GB memory space).
Now that you mention it, yeah, it was NOT because of windows. Unfortunately I only started to work with computers around MS-DOS 3.3 and Windows 3.0 (I don't know the time-line, but those were my first OS and then GUI). I only got introduced to linux and networks in 1995 (1st high-school year). My point is that text transfers are murderers to binary files. I have not encountered any binary file over 50K that was not damaged (can you say missing 1 byte). But no damage to files because of network failiure. I did have a damaging transfer with NetBIOS (the 3rd protocol used in Win95 besides TCP/IP and IPX).
Since before I started working here, they've been using FTP to upload the files, but many times the copied files are a few kilobytes smaller than the originals.
Are you sure you are using BINARY transfers? FTP allows "text" tranfers which can transform the CR+LF pair into 1 byte (CR I think). On large files, you could end-up with several KB missing. This transformation actually depends on client and server, not OS (although it was created because of Windows - Unix conventions).
Regarding what others have said, I don't see how TCP checksumming could affect the file unless a specific attack is made. Even then, it's hard to block the original TCP packet, and altering it will make the receiver transmit a "retransmission request". (I said hard, not impossible)
So the bankruptcy administrators should either pay for relocation of the DRM servers or, the shifting of the licences to a different provider or a patch to remove the now DMCA infringing DRM protection as a failure to provide access to the DRM servers actually does break the copyright protection method under law.
I was just thinking.....if this is true (I'm not in the US and I don't know about DMCA) then all the companies are thinking one of the following things: 1. "We are invincible and always prevail" 2. "Our products are so bad, they don't deserve to remain after us". In the case of 1, they should look in other domains for their beliefs. In case of 2....no more comments.
Please stop comparing su/sudo to UAC. Compare su to the old run-as and sudo has no equivalence in windows. Besides, those are very simple programs compared to UAC. And they did have bugs at the beginning. And you still can leave you system open to attacks with them. But they are safer if Joe Average installs a distribution and just uses it. My problem with UAC is that it still does not stop the admin account from being used all the time. This still leaves lazy (or beginner) programmers in a position to NOT update their programs. And they even can instruct their customers to disable UAC and still use the admin account. And popping-up mid-runtime is not always a good idea. Someone already gave an example that it can appear during a fullscreen game session and it had no relevance to the game. I may accept the idea of popping-up to a foreground application, but if I'm gaming and suddenly yahoo messenger wants to update itself I would get angry very fast.
That's it...no more comments from me. I just wanted to highlight that windows installer still is targeted at knowledgeable people and not Joe Average and that is where MS should make changes. Most infected computers are those running default configurations (pre-SP2 XP most likely).
To be fair, this is not a bug in UAC. Its a bug in the default permissions - allowing non-administrators to change whether UAC is enabled (probably bad ACLs on a registry key - well if you consider don't consider config permissions part of UAC - but you see what I'm getting at).
Yes, it is a bug in UAC "package"....but who can say there are no more bugs in the same manner? Making workarouns for workarounds is a bad idea. Sometimes you just have to change things. Keep it simple. The more complex a code is, the more bugs it can have. Also with every fix a new bug can arrive.
If a privileged process accepts instructions from just about anyone - then your install is boned.
But UAC does run with admin priviledges if the account is admin.
When it comes down to it, users are too stupid to understand the complexity of the tool they are using. So we can try and hide it - but they'll still hammer away with a silly monkey-grin on their faces - and even if we take their damn admin rights away they'll be demanding we install "LOLCat Viewer with The Sub Seven Trojan" until they're blue in the face
So let them be blue in the face. Explain them what can happen. Make them sign that "responsability" clause. The idea is that they need to be informed. My opinion: in 90% of the cases they will abandon the idea. And that would be enough for malware programmers to stop trying this kind of social engineering. Even if they have the admin password, just by having to type it in will alert them more. Users are "trained" to click "ok" in web pages, but not to type passwords in them.
joke:And even if they insist, at least you can tell them "I told you so" when they do get in trouble./joke
My point is that for an admin account UAC is useless. They should just create limited users by default and not expect someone to create them manually (as the initial point of the "professional" editions, before scrapping 9x). Also they should not allow admin accounts with no password or auto-login (maybe with a limited nr. of resets).
I understand what you are getting at here - but its really no different to being a member of wheel and being able to sudo without a password.
Yes, you are right. However, is there any distribution that does this from installation? So if this is done, it was done by the user.
As a logged in member of the Administrators group your processes are not running with superuser privileges. Elevation must be approved using the UAC prompts.
As I understood, one of Windows 7 public beta bugs is that UAC could be turned off "without UAC prompt". That means after the restart and login with same user all applications start as administrators, not restricted admin. This is a perfect timing for a malware which previously put itself to start just for that user. After the restart, it can put itself for all users. Don't get me wrong, I may like the idea of changing priviledges during runtime, but I'm totally against the idea of regular-no-computer-knowledge-users having to just click "ok" on an administrative prompt. MS should really enforce limited user accounts. Who knows how many bugs could appear in UAC? In security, it is good to be paranoid.
so that even "Administrator" can be locked out of files such as the ones put on there by malware
But HOW did that file got there? Because it was written by a process that ran with admin rights. And having those rights, it could make it be executed BEFORE an admin user has manual control EVERY TIME (even safe mode). I feel a "dog chasing it's tail" situation? Trust me, I can have many ideas to return to the "default user is an admin" whipping. I already said: 2K/XP/Vista/7 installations all assume that someone installs the system AND MANUALLY CREATES LIMITES USER ACCOUNTS. THIS DOES NOT HAPPEN IN HOME ENVIROMENTS. This is what they have to change. And I also vote to eliminate UAC totally.
What bothers me is nobody seems to answer the question: "What *should* they be doing?" in a reasonable manner.
Valid point. Here is my summary: 1.Change the installation steps to create limited users, not admin users by default. 2.Improve run-as functionality. Currently, I have the following problems:
XP: run-as by defaults selects "restricted priviledges". You need 2 down-arrows to select "the following user" which by default is "Administrator", so I need the 3rd down-arrow to choose my admin account.
Vista: shows only user/password boxes (good) but an user-selection list would be nice (like XP).
Windows 7 public beta: same as Vista, except that for some reason explorer.exe WILL NOT RUN as another user (extremely annoying).
Currently in XP you have "run-as" on almost all applications. In Vista and W7 beta you have "Run as Administrator" which start UAC and you need to shift+right-click to see "run-as". This is also the case of XP control panel items. Also, as I recall, in Vista if you disable UAC the "Run as administrator" dissappears. In W7 it remains but does nothing (again annoying).
And realted to explorer.exe, you need to set "Launch folder windows in a separate process" for both, the current user and admin user, otherwise you will only get the logged-in user priviledges. But for some reason, this does not seem to work in Windows 7 beta.
Of course, the problem in some ways is not even MS's fault. The reality is most Windows programs are doing things that trigger UAC prompts for no good reason. In the linux world, if an text editor or card game or whatever app required you to su every time you ran it, even when it didn't perform any functions that actually needed su level privileges, people would be pissed. But there's a lot of Windows apps that need to run as admin, even when their primary function has no need for admin level privileges. Their coders were just lazy, and instead of doing things following MS's guidelines, they take shortcuts that lead to big headaches for everyone down the line.
But you foget one thing: if MS would have forced Joe Average to use a limited account, programmers would not have the option to take those shortcuts. The big mistake from MS was that when they replaced Win9x with 2000/XP, they DID NOT change the install steps and the original "workstation" installation was assumed where an admin installs the OS and then he creates user accounts. This is something that Joe Average never does for his home system. And the systems that are "bitten" by malware are mostly this kind of systems. So if MS will not break this pattern, they WILL suffer in OS department. In 5 years or 10, they will. My personal reasons to still stay with Windows are (in this order) games, Total Commander and "defragmenting". And the games are starting to fade in my view.
Right.... But I still don't like it this way. I also would like a "continue with limited" or "simulate success" option besides allow (continue as admin) and cancel (interrupt the action completely). I already sent a feedback to MS.
Nevertheless, UAC is a priviledge lowering concept, not a priviledge elevation. So while you log-in with admin, there will be always be a way to go around. In security you need to start each program with "presume guilty", not "innocent until proven guilty" (as UAC does). Even 2 bugs rated "not important/low risk" may open a door for someone that can exploit them both at once. Definition of catastrophe: 2 or more mistakes made at the same time. UAC is just one waiting to happen. It's mistake: overconfidence that UAC will show you everything. Reality: I already seen news that some ways were found to go around UAC.
MS should have made the default installation to create 2 accounts and forget everything about UAC. Even ubuntu's way of installing is safer: no root password, but every app that requires admin priviledges HAS to be executed under sudo or gksudo. Any other way is controlled by package creators/maintainers which are recommended to use app-specific groups and not root account/group, hence a bug would affect only that functionality, not the whole system.
I'm really puzzled: in all these years MS tried to copy many competitors and broke several applications with a new version, but this time they opted to this UAC concept which keeps several bad-behaving apps working instead of copying su/sudo-concept (ok... su concept is already implemented as run-as).
PS: I think UAC is created as a "trigger" to certain events. So what happens if MS missed a spot?
Let's not forget WHY UAC was created: normal users (with little or no computer experience) used windows with an admin account (thank you legacy DOS and Microsofts reluctance to break the pattern). So any rogue program could install itself for ALL users. MS instead of enforcing limited accounts, they created UAC. My opinion: DO NOT USE UAC. EVER. For a computer with only 1 user, CREATE 2 ACCOUNTS, 1 admin and 1 limited. Their reasons (probably): not breaking applications which were created badly in the 1st place (which required admin rights for everyday use). I work for a big company (multi-national, 100.000+ employees) and I can tell you: LIMITED ACCOUNTS WORK. You want to install something, either do it only for you (if the installer does not complain), or ASK AN ADMIN. Someone who really knows what is doing. I use at home the 2-account setup since over 3 years, and it's great. My only problem is that some installers refuse to run without admin rights.
I have tried Vista a long time ago and I don't remember what I though about UAC then. But now I've tried Windows 7 and I ended up disabling UAC (I started with 2-account setup form the beginning). My only problem: an explorer window can no longer be started as different user (run as). Although I do get the user/password prompt, it still starts as the logged-on user (defeating the run-as concept). Too bad because almost all control panel items are based on explorer.
You comment made me think. I really don't know if it's like this, but: An LCD cell can "hold" only one state without an electrical field. So why the monitors are called "sample-and-hold"? Because each LCD cell is controlled by a TFT (thin-film-transistor; so the correct way to call it is TFT+LCD, not TFT or LCD). The TFT is just like DRAM: you give it a charge and it holds it (over the LCD cell). But if you don't refresh the charge, it will loose it's charge. But unlike DRAM (which have much much much.... much higher density), you can hold the charge much more. Infact a 60Hz screen will not loose noticeable color; my estimate: at least 95% charge in 20ms. Compare that with 8ms (I remember this from SD-RAM BIOS settings) required refresh cycle for DRAM (where around 50-60% charge or less is the threshold for 1 or 0).
Actually grey-to-grey measurement is correct. It's not to 50%. It's the time a requested shade (not black or white) turns to another requested shade. On TN matrices, changes from pure black to pure white (or reverse) is done very fast compared to changing between 2 shades of grey. So they give the grey-to-grey which represent a "worst-case" timing. See http://www.xbitlabs.com/articles/monitors/display/lcd-guide_2.html#sect0, although it's an old article (2004) it is still good reading material. Quote: "Measurements suggest that the response time is the smallest when the pixel's state (color) is transitioning from black to white."
What's confusing is that the address space of processes and the physical memory addressable by the CPU happen to be the same.
I read this 3 times until I really understood what you meant. But yes, that is what's confusing. If I would correct your sentence, I would change it to "... happen to have the same limit." I guess that's why they're 32-bit processors: main registers and pointers are 32-bit. By pointers I'm also refering to the contents of page translation tables (or whatever they are called), which link the virtual address to the physical address.
If you have a true HW RAID then it's utility should give you access to SMART statistics. But since most RAIDs in less than $10.000 computers are software RAID, they just "replace" the 2 drives with 1. So there is not direct access to the drives because of reliability. And since they are CHEAP solutions, they don't bother with utilities for checking the drives. After all, SMART is a standars set of commands and responses which any utility can use them (not only HDD-vendor-specific)
32-bit x86 means: -ONE application has a 4GB limit (well, 2GB actually, the rest is reserved for kernel mapping) -CPU CANNOT access more than 4GB of PHYSICAL address space (without PAE)
So that means you can have 10 apps that each actively use 2GB and still be on a 32-bit non-PAE system (20GB virtual ram). So yeah, running 4GB or RAM on a 32-bit NT/2K/XP/Vista can still "use" 8GB swap space. It's just that you would be better off with 64-bit OS and 8GB of RAM if you need more than 1GB of swap.
But AFAIK you don't have to wait in a loop for the seek to finish.
PIO was used during XT era and DOS where you had only 8 non-shareable IRQ lines. Having an interrupt for HDD was just not feasible. So after making a request, you had to keep polling that port and know when the actual data was given (ATA specs). This was no problem under DOS. But once multitasking appeared on the PC, DMA was needed (you can probably look for ATA specs on wikipedia). The idea is that PIO is the most reliable way, because it uses only 3 bytes (I think) of memory-map region and the controller needs only to send it's data at certain periods. And all DMA modes until UDMA were poorly implemented in some chips. The problem with Windows IDE drivers is that they fall-back to PIO but then do not allow you to return to DMA (at least in an easy way). While falling back can be a result of poor cable (in which case it can be justified), it can also be triggered by some bad sectors.
You're like someone who drives a Ferrari and when it breaks down he has to call the service...oh wait...there is no service because all the technical people are extinct since the new ones DID NOT learn the old ways.
I'm sure this kind of (programming) thinking is why Vista had so many bad reviews from enthusiasts.
And without those boring interrupt calls and HW access you would not have any other high-level language and you would be stuck in the old platforms (compatibility). Someone still has to do the dirty work.
I so hate the idea of "everyone can be a programmer".
I don't know the details of the jumbo frames (like negotiations, if any), but I do know that at least the communicating points (hosts and switch) need to "know" it. But I see it as mainly a "switch helper". Think of an 8-point switch with 8 hosts and all of them transferring at maximum speed. So if you can send 1 big packet instead of 6, you can help the switch very much. Although the ehternet checksum is done on the same size (wether it's 6 1.5K packets or 1 9K), the overhead and switching are done 6-times less. So the jumbo frames will not give you much higher speeds (mainly the overhead 18 bytes/packet of the 5 packets that are sent if jumbo frames are disabled) unless your network is congested. But like you said: compatibility within the network is questionable. In my previous post I said that there was a problem (although I did not say it was about usage and not bandwidth), but not that the jumbo frames will give you always a speed boost.
Do not assume 1Gb ethernet is >= 100Mb ethernet for throughput unless you have numbers to back it up.
The problem with ethernet at 1Gbyte speeds was the limit of 1500-byte ethernet frame. So they added 9KB jumbo frames, but these are not supported by early devices (switches or cards). So if you do not use jumbo frames, you can easily bring down your cheap switch.
I can tell you that I am using one router (PC with linux) with 1 laptop 7200 HDD (for torrents) and my gaming rig with no RAID in any of them. I can transfer 20-25MB/s because that is the limit of the 2.5" 7200rpm HDD. So my switch (TP-link 8-port all-gigabit) throught which all my network is connected has the bandwidth. But this is with big files (100+MB).
For small files the file-system overhead and incomplete ethernet/IP packets have a big penalty to network speeds AND HDD reads/writes. Also, the busier the network is, the worst the performance is. Keep in mind that the higher latency you have, the lower speed you're gonna get. Especially with windows file sharing (SMB). While experimenting with a local cascading 100Mbps network, I saw that SMB was affected if you communicated through 2 switches (10MB/s) vs. 4 switches (7-8MB/s). The Server (test source) was the same but the client did not affect the result, because for FTP I got same speeds (10MB/s at 2 or 4 switches). There was one test file around 600MB in size.
I tried a 1Ge that allowed an internal 2-disk RAID-0, setup. The best it would do was about 12MB/s read, 7-8MB/s write.
From what I understand only one "device" had RAID setup. So maybe the other end (which was not RAID) could not handle more speed. Remember that when you copy, you have the speed of the weakest link. You would not expect to copy at RAID speed from a CD/DVD.
I really don't think you want to "write" even a 512-bits key. 512 bits means 64 bytes, but they are not human-readable. To make a human-readable key you need to convert it to another format (like base64, uue etc.) which means another algorithm, another skill and human error (I even have trouble with game keys that are 5x5 long). If you mean a password then you should know that either the key is created from that password or the real key is encrypted with that password. In any case, you still need the algorithm that created the key from the password, which in 10 years could be scrapped and todays applications (which use it) may not run on future computers (ok...this is a little exageration, but I'm obsessed by "worst-case scenario").
Achiving is a big compromise between availability and security. The security part can have many points of failiure which could render the archive unreadable.
You all talk about encrypting, but did you ever think about the key? What if you loose your key? Maybe in the future you will use another key and forget about the one you used for achiving. And when you need the data......where did you put that key?
I already started using one DVD-R disk and one DVD-RW disk for each archive. While I can check in the future and possibly retrieve damaged data from at least one, I'm thinking what will happen when I'll have 100 archives? Will I allocate 1 year to check 2disks/week?
Slashdot Mirror
It is cheaper in the long run just to make the switch to x64 than it is trying to make a hack work, especially a bad hack like over 4Gb support in an OS released in 2001
The hack is PAE, and is HW-related. 32-bit has a 4GB limitation/app which will NEVER be changed (unless recompiling to 64-bit). PAE allows and OS to use more than 4GB, but in client XP (Home/Professional) it was limited by SW. :
Pentium Pro (1995) was the 1st processor with PAE (36-bit address lanes). Windows 2000 already had a PAE implementation.
From http://en.wikipedia.org/wiki/Windows_2000
Windows 2000 Advanced Server is a variant of Windows 2000 Server operating system designed for medium-to-large businesses. It offers clustering infrastructure for high availability and scalability of applications and services, including main memory support of up to 8 gigabytes (GB) on Physical Address Extension (PAE) systems and the ability to do 8-way SMP.
WRONG!! WRONG!! WRONG!!
You are confusing virtual (app) memory and physical memory.
Virtual memory is ALWAYS limited to 4GB (with 2/2GB or 3/1GB split of user/kernel) on 32-bit, PAE or not, Workstation or Server.
PAE allows for more than 4GB PHYSICAL memory. That means you could have 2 3GB apps running all in RAM (no swap) in 6+GB RAM.
For ONE app to use more than 4GB, you NEED 64-bit.
Each application page (usually 4K) is mapped to physical space, whether it's RAM or swap (when idle of course). The PAE allows you to map a page on more than 4GB RAM. This is done entirely by OS.
The problem is that drivers need to know the physical address, because that is what HW devices can access. Some drivers are poorly implemented and fail to do this (like giving a 32-bit address when they sould give 36-bit to the HW).
For a server, the company usually has an IT department that can get certified HW (not off-the-shelf cheap HW) and they usually test the server before deploying. So any driver issue can be corrected (either change the HW or resolve the driver issue) before deployment.
So MS did not want to get calls of data corruption and limited PAE on client windows. My problem (and the article's author's) is that WE (tech-savy computer users) cannot activate it afterwards.
PS: PAE was implemented since Pentium Pro. As I recall it already had 36-lines for adresses (that is 64GB memory space).
Now that you mention it, yeah, it was NOT because of windows. Unfortunately I only started to work with computers around MS-DOS 3.3 and Windows 3.0 (I don't know the time-line, but those were my first OS and then GUI). I only got introduced to linux and networks in 1995 (1st high-school year).
My point is that text transfers are murderers to binary files. I have not encountered any binary file over 50K that was not damaged (can you say missing 1 byte). But no damage to files because of network failiure. I did have a damaging transfer with NetBIOS (the 3rd protocol used in Win95 besides TCP/IP and IPX).
Since before I started working here, they've been using FTP to upload the files, but many times the copied files are a few kilobytes smaller than the originals.
Are you sure you are using BINARY transfers? FTP allows "text" tranfers which can transform the CR+LF pair into 1 byte (CR I think). On large files, you could end-up with several KB missing. This transformation actually depends on client and server, not OS (although it was created because of Windows - Unix conventions).
Regarding what others have said, I don't see how TCP checksumming could affect the file unless a specific attack is made. Even then, it's hard to block the original TCP packet, and altering it will make the receiver transmit a "retransmission request". (I said hard, not impossible)
So the bankruptcy administrators should either pay for relocation of the DRM servers or, the shifting of the licences to a different provider or a patch to remove the now DMCA infringing DRM protection as a failure to provide access to the DRM servers actually does break the copyright protection method under law.
I was just thinking.....if this is true (I'm not in the US and I don't know about DMCA) then all the companies are thinking one of the following things:
1. "We are invincible and always prevail"
2. "Our products are so bad, they don't deserve to remain after us".
In the case of 1, they should look in other domains for their beliefs. In case of 2....no more comments.
Oh, and this applies to games, music and movies.
Please stop comparing su/sudo to UAC. Compare su to the old run-as and sudo has no equivalence in windows. Besides, those are very simple programs compared to UAC. And they did have bugs at the beginning. And you still can leave you system open to attacks with them. But they are safer if Joe Average installs a distribution and just uses it.
My problem with UAC is that it still does not stop the admin account from being used all the time. This still leaves lazy (or beginner) programmers in a position to NOT update their programs. And they even can instruct their customers to disable UAC and still use the admin account.
And popping-up mid-runtime is not always a good idea. Someone already gave an example that it can appear during a fullscreen game session and it had no relevance to the game. I may accept the idea of popping-up to a foreground application, but if I'm gaming and suddenly yahoo messenger wants to update itself I would get angry very fast.
That's it...no more comments from me. I just wanted to highlight that windows installer still is targeted at knowledgeable people and not Joe Average and that is where MS should make changes. Most infected computers are those running default configurations (pre-SP2 XP most likely).
To be fair, this is not a bug in UAC. Its a bug in the default permissions - allowing non-administrators to change whether UAC is enabled (probably bad ACLs on a registry key - well if you consider don't consider config permissions part of UAC - but you see what I'm getting at).
Yes, it is a bug in UAC "package" ....but who can say there are no more bugs in the same manner? Making workarouns for workarounds is a bad idea. Sometimes you just have to change things. Keep it simple. The more complex a code is, the more bugs it can have. Also with every fix a new bug can arrive.
If a privileged process accepts instructions from just about anyone - then your install is boned.
But UAC does run with admin priviledges if the account is admin.
When it comes down to it, users are too stupid to understand the complexity of the tool they are using. So we can try and hide it - but they'll still hammer away with a silly monkey-grin on their faces - and even if we take their damn admin rights away they'll be demanding we install "LOLCat Viewer with The Sub Seven Trojan" until they're blue in the face
So let them be blue in the face. Explain them what can happen. Make them sign that "responsability" clause. The idea is that they need to be informed. My opinion: in 90% of the cases they will abandon the idea. And that would be enough for malware programmers to stop trying this kind of social engineering. Even if they have the admin password, just by having to type it in will alert them more. Users are "trained" to click "ok" in web pages, but not to type passwords in them.
joke:And even if they insist, at least you can tell them "I told you so" when they do get in trouble. /joke
My point is that for an admin account UAC is useless. They should just create limited users by default and not expect someone to create them manually (as the initial point of the "professional" editions, before scrapping 9x). Also they should not allow admin accounts with no password or auto-login (maybe with a limited nr. of resets).
I understand what you are getting at here - but its really no different to being a member of wheel and being able to sudo without a password.
Yes, you are right. However, is there any distribution that does this from installation? So if this is done, it was done by the user.
As a logged in member of the Administrators group your processes are not running with superuser privileges. Elevation must be approved using the UAC prompts.
As I understood, one of Windows 7 public beta bugs is that UAC could be turned off "without UAC prompt". That means after the restart and login with same user all applications start as administrators, not restricted admin. This is a perfect timing for a malware which previously put itself to start just for that user. After the restart, it can put itself for all users.
Don't get me wrong, I may like the idea of changing priviledges during runtime, but I'm totally against the idea of regular-no-computer-knowledge-users having to just click "ok" on an administrative prompt.
MS should really enforce limited user accounts. Who knows how many bugs could appear in UAC? In security, it is good to be paranoid.
so that even "Administrator" can be locked out of files such as the ones put on there by malware
But HOW did that file got there? Because it was written by a process that ran with admin rights. And having those rights, it could make it be executed BEFORE an admin user has manual control EVERY TIME (even safe mode).
I feel a "dog chasing it's tail" situation? Trust me, I can have many ideas to return to the "default user is an admin" whipping.
I already said: 2K/XP/Vista/7 installations all assume that someone installs the system AND MANUALLY CREATES LIMITES USER ACCOUNTS. THIS DOES NOT HAPPEN IN HOME ENVIROMENTS. This is what they have to change. And I also vote to eliminate UAC totally.
What bothers me is nobody seems to answer the question: "What *should* they be doing?" in a reasonable manner.
Valid point. Here is my summary:
1.Change the installation steps to create limited users, not admin users by default.
2.Improve run-as functionality.
Currently, I have the following problems:
XP: run-as by defaults selects "restricted priviledges". You need 2 down-arrows to select "the following user" which by default is "Administrator", so I need the 3rd down-arrow to choose my admin account.
Vista: shows only user/password boxes (good) but an user-selection list would be nice (like XP).
Windows 7 public beta: same as Vista, except that for some reason explorer.exe WILL NOT RUN as another user (extremely annoying).
Currently in XP you have "run-as" on almost all applications. In Vista and W7 beta you have "Run as Administrator" which start UAC and you need to shift+right-click to see "run-as". This is also the case of XP control panel items.
Also, as I recall, in Vista if you disable UAC the "Run as administrator" dissappears. In W7 it remains but does nothing (again annoying).
And realted to explorer.exe, you need to set "Launch folder windows in a separate process" for both, the current user and admin user, otherwise you will only get the logged-in user priviledges. But for some reason, this does not seem to work in Windows 7 beta.
Program: I'm a flash demo and I just need 1 micro-second to add a registry key"
User: "ok then"
Opps, the key was HKLM/Software/Microsft/Windows/CurrentVersion/Run which affects ALL users.
That is the real problem with malware.
Of course, the problem in some ways is not even MS's fault. The reality is most Windows programs are doing things that trigger UAC prompts for no good reason. In the linux world, if an text editor or card game or whatever app required you to su every time you ran it, even when it didn't perform any functions that actually needed su level privileges, people would be pissed. But there's a lot of Windows apps that need to run as admin, even when their primary function has no need for admin level privileges. Their coders were just lazy, and instead of doing things following MS's guidelines, they take shortcuts that lead to big headaches for everyone down the line.
But you foget one thing: if MS would have forced Joe Average to use a limited account, programmers would not have the option to take those shortcuts.
The big mistake from MS was that when they replaced Win9x with 2000/XP, they DID NOT change the install steps and the original "workstation" installation was assumed where an admin installs the OS and then he creates user accounts. This is something that Joe Average never does for his home system. And the systems that are "bitten" by malware are mostly this kind of systems.
So if MS will not break this pattern, they WILL suffer in OS department. In 5 years or 10, they will. My personal reasons to still stay with Windows are (in this order) games, Total Commander and "defragmenting". And the games are starting to fade in my view.
Right.... But I still don't like it this way. I also would like a "continue with limited" or "simulate success" option besides allow (continue as admin) and cancel (interrupt the action completely). I already sent a feedback to MS.
Nevertheless, UAC is a priviledge lowering concept, not a priviledge elevation. So while you log-in with admin, there will be always be a way to go around.
In security you need to start each program with "presume guilty", not "innocent until proven guilty" (as UAC does).
Even 2 bugs rated "not important/low risk" may open a door for someone that can exploit them both at once.
Definition of catastrophe: 2 or more mistakes made at the same time. UAC is just one waiting to happen. It's mistake: overconfidence that UAC will show you everything. Reality: I already seen news that some ways were found to go around UAC.
MS should have made the default installation to create 2 accounts and forget everything about UAC. Even ubuntu's way of installing is safer: no root password, but every app that requires admin priviledges HAS to be executed under sudo or gksudo. Any other way is controlled by package creators/maintainers which are recommended to use app-specific groups and not root account/group, hence a bug would affect only that functionality, not the whole system.
I'm really puzzled: in all these years MS tried to copy many competitors and broke several applications with a new version, but this time they opted to this UAC concept which keeps several bad-behaving apps working instead of copying su/sudo-concept (ok... su concept is already implemented as run-as).
PS: I think UAC is created as a "trigger" to certain events. So what happens if MS missed a spot?
Let's not forget WHY UAC was created: normal users (with little or no computer experience) used windows with an admin account (thank you legacy DOS and Microsofts reluctance to break the pattern). So any rogue program could install itself for ALL users.
MS instead of enforcing limited accounts, they created UAC.
My opinion: DO NOT USE UAC. EVER. For a computer with only 1 user, CREATE 2 ACCOUNTS, 1 admin and 1 limited. Their reasons (probably): not breaking applications which were created badly in the 1st place (which required admin rights for everyday use).
I work for a big company (multi-national, 100.000+ employees) and I can tell you: LIMITED ACCOUNTS WORK. You want to install something, either do it only for you (if the installer does not complain), or ASK AN ADMIN. Someone who really knows what is doing.
I use at home the 2-account setup since over 3 years, and it's great. My only problem is that some installers refuse to run without admin rights.
I have tried Vista a long time ago and I don't remember what I though about UAC then. But now I've tried Windows 7 and I ended up disabling UAC (I started with 2-account setup form the beginning). My only problem: an explorer window can no longer be started as different user (run as). Although I do get the user/password prompt, it still starts as the logged-on user (defeating the run-as concept). Too bad because almost all control panel items are based on explorer.
You comment made me think. I really don't know if it's like this, but: .... much higher density), you can hold the charge much more. Infact a 60Hz screen will not loose noticeable color; my estimate: at least 95% charge in 20ms. Compare that with 8ms (I remember this from SD-RAM BIOS settings) required refresh cycle for DRAM (where around 50-60% charge or less is the threshold for 1 or 0).
An LCD cell can "hold" only one state without an electrical field. So why the monitors are called "sample-and-hold"? Because each LCD cell is controlled by a TFT (thin-film-transistor; so the correct way to call it is TFT+LCD, not TFT or LCD). The TFT is just like DRAM: you give it a charge and it holds it (over the LCD cell). But if you don't refresh the charge, it will loose it's charge. But unlike DRAM (which have much much much
Actually grey-to-grey measurement is correct. It's not to 50%. It's the time a requested shade (not black or white) turns to another requested shade. On TN matrices, changes from pure black to pure white (or reverse) is done very fast compared to changing between 2 shades of grey. So they give the grey-to-grey which represent a "worst-case" timing.
See http://www.xbitlabs.com/articles/monitors/display/lcd-guide_2.html#sect0, although it's an old article (2004) it is still good reading material.
Quote: "Measurements suggest that the response time is the smallest when the pixel's state (color) is transitioning from black to white."
What's confusing is that the address space of processes and the physical memory addressable by the CPU happen to be the same.
I read this 3 times until I really understood what you meant. But yes, that is what's confusing. If I would correct your sentence, I would change it to "... happen to have the same limit."
I guess that's why they're 32-bit processors: main registers and pointers are 32-bit. By pointers I'm also refering to the contents of page translation tables (or whatever they are called), which link the virtual address to the physical address.
If you have a true HW RAID then it's utility should give you access to SMART statistics.
But since most RAIDs in less than $10.000 computers are software RAID, they just "replace" the 2 drives with 1. So there is not direct access to the drives because of reliability. And since they are CHEAP solutions, they don't bother with utilities for checking the drives. After all, SMART is a standars set of commands and responses which any utility can use them (not only HDD-vendor-specific)
32-bit x86 means:
-ONE application has a 4GB limit (well, 2GB actually, the rest is reserved for kernel mapping)
-CPU CANNOT access more than 4GB of PHYSICAL address space (without PAE)
So that means you can have 10 apps that each actively use 2GB and still be on a 32-bit non-PAE system (20GB virtual ram).
So yeah, running 4GB or RAM on a 32-bit NT/2K/XP/Vista can still "use" 8GB swap space. It's just that you would be better off with 64-bit OS and 8GB of RAM if you need more than 1GB of swap.
But AFAIK you don't have to wait in a loop for the seek to finish.
PIO was used during XT era and DOS where you had only 8 non-shareable IRQ lines. Having an interrupt for HDD was just not feasible. So after making a request, you had to keep polling that port and know when the actual data was given (ATA specs). This was no problem under DOS.
But once multitasking appeared on the PC, DMA was needed (you can probably look for ATA specs on wikipedia). The idea is that PIO is the most reliable way, because it uses only 3 bytes (I think) of memory-map region and the controller needs only to send it's data at certain periods. And all DMA modes until UDMA were poorly implemented in some chips.
The problem with Windows IDE drivers is that they fall-back to PIO but then do not allow you to return to DMA (at least in an easy way). While falling back can be a result of poor cable (in which case it can be justified), it can also be triggered by some bad sectors.
You're like someone who drives a Ferrari and when it breaks down he has to call the service...oh wait...there is no service because all the technical people are extinct since the new ones DID NOT learn the old ways.
I'm sure this kind of (programming) thinking is why Vista had so many bad reviews from enthusiasts.
And without those boring interrupt calls and HW access you would not have any other high-level language and you would be stuck in the old platforms (compatibility). Someone still has to do the dirty work.
I so hate the idea of "everyone can be a programmer".
I don't know the details of the jumbo frames (like negotiations, if any), but I do know that at least the communicating points (hosts and switch) need to "know" it. But I see it as mainly a "switch helper". Think of an 8-point switch with 8 hosts and all of them transferring at maximum speed. So if you can send 1 big packet instead of 6, you can help the switch very much. Although the ehternet checksum is done on the same size (wether it's 6 1.5K packets or 1 9K), the overhead and switching are done 6-times less.
So the jumbo frames will not give you much higher speeds (mainly the overhead 18 bytes/packet of the 5 packets that are sent if jumbo frames are disabled) unless your network is congested.
But like you said: compatibility within the network is questionable.
In my previous post I said that there was a problem (although I did not say it was about usage and not bandwidth), but not that the jumbo frames will give you always a speed boost.
Do not assume 1Gb ethernet is >= 100Mb ethernet for throughput unless you have numbers to back it up.
The problem with ethernet at 1Gbyte speeds was the limit of 1500-byte ethernet frame. So they added 9KB jumbo frames, but these are not supported by early devices (switches or cards). So if you do not use jumbo frames, you can easily bring down your cheap switch.
I can tell you that I am using one router (PC with linux) with 1 laptop 7200 HDD (for torrents) and my gaming rig with no RAID in any of them. I can transfer 20-25MB/s because that is the limit of the 2.5" 7200rpm HDD. So my switch (TP-link 8-port all-gigabit) throught which all my network is connected has the bandwidth. But this is with big files (100+MB).
For small files the file-system overhead and incomplete ethernet/IP packets have a big penalty to network speeds AND HDD reads/writes. Also, the busier the network is, the worst the performance is. Keep in mind that the higher latency you have, the lower speed you're gonna get. Especially with windows file sharing (SMB). While experimenting with a local cascading 100Mbps network, I saw that SMB was affected if you communicated through 2 switches (10MB/s) vs. 4 switches (7-8MB/s). The Server (test source) was the same but the client did not affect the result, because for FTP I got same speeds (10MB/s at 2 or 4 switches). There was one test file around 600MB in size.
I tried a 1Ge that allowed an internal 2-disk RAID-0, setup. The best it would do was about 12MB/s read, 7-8MB/s write.
From what I understand only one "device" had RAID setup. So maybe the other end (which was not RAID) could not handle more speed. Remember that when you copy, you have the speed of the weakest link. You would not expect to copy at RAID speed from a CD/DVD.
I really don't think you want to "write" even a 512-bits key. 512 bits means 64 bytes, but they are not human-readable. To make a human-readable key you need to convert it to another format (like base64, uue etc.) which means another algorithm, another skill and human error (I even have trouble with game keys that are 5x5 long).
If you mean a password then you should know that either the key is created from that password or the real key is encrypted with that password. In any case, you still need the algorithm that created the key from the password, which in 10 years could be scrapped and todays applications (which use it) may not run on future computers (ok...this is a little exageration, but I'm obsessed by "worst-case scenario").
Achiving is a big compromise between availability and security. The security part can have many points of failiure which could render the archive unreadable.
You all talk about encrypting, but did you ever think about the key? What if you loose your key? Maybe in the future you will use another key and forget about the one you used for achiving. And when you need the data......where did you put that key?
I already started using one DVD-R disk and one DVD-RW disk for each archive. While I can check in the future and possibly retrieve damaged data from at least one, I'm thinking what will happen when I'll have 100 archives? Will I allocate 1 year to check 2disks/week?