Slashdot posting has been down for two hours now. Attempts to post are greeted with the rude message, "Database maintenance is currently taking place.". Two hours to do database maintenance? Give me a break!
p.s. They're still managing to put stories up on the front page though. Go figure.
p.p.s. I checked back, and posting is still down after four hours.
I've had one particularly scrupulous person ask whether reprinting things that I've written on Slashdot is acceptable. I consider any content I've written freshly for Slashdot to be public domain -- it'd be nice (though not a requirement) for you to attribute me (as 0x0d0a on Slashdot). You can use what I've written here however you'd like.
There is one caveat that you should consider: If I'm quoting something that has previously been written elsewhere, by someone else (or me), I can't necessarily place that into the public domain. If I use a snippit of source code from the Linux kernel, obviously I can't simply put it in the public domain. Other than that, have fun with it!
I'm putting this in my journal instead of a Slashdot post because the lameness filter keeps eating my Slashdot post. If you have a response, please just respond to my Slashdot post.
I was empirically analyzing the gcc 3.3.3 optimizer a couple of days ago. Some interesting points:
* gcc does not appear to take advantage of the iso c99 "restrict" keyword, which can allow for significant performance improvements. The "restrict" keyword allows one to indicate to the compiler that a pointer is not an "alias" (pointer to the same location) as any other pointer available to the function, nor does it point to anything that points to anything and so forth that is aliased. Without this hinting, C compilers have a very difficult time dealing with optimizations across function calls.
* I can't seem to find any way to convince gcc to dump out its parse tree before doing any optimization. It'd be nice if I could convince it to do so -- I *know* that there's something less processed than -dr output.
* The following main() code optimizes rather entertainingly:
c=0;
if (argc == 6) {
c++;
if ((argc % 6) == 0)
c++;}
return c;
Compiles to (non-pertient sections removed):
xorl %ecx, %ecx
cmpl $6, %eax
je
L2:
movl %ecx, %eax
leave
ret
L4:
cltd
idivl %eax
testl %edx, %edx
movl $1, %ecx
jne
movl $2, %ecx
jmp
Now, gcc's optimizer is clearly clever enough to figure out that argc has the value 6. However, it takes advantage of that fact...by using argc to divide argc! These two conditionals should have compiled down to cmpl, je, mov, jmp, mov, ret.
Currently, the color model used on workstation computers is very lacking in dynamic range. It cannot reach levels that are nearly bright enough. The real world contains sun sparkling on the water, car headlights, and the outdoors. Currently, a normal computer environment can only reproduce the brightness of a sheet of paper. This is a blocking issue to producing realistic virtual worlds and images.
This is a legacy problem dating back to old monochrome monitors, where there were only two shades of color to work with. Naturally, text was represented as full white (or black) and the text's background as the opposite color. This meant that white's brightness could be turned far up, but it would be very uncomfortable for the user -- if the monitor had a white as bright as car headlamps, then anyone reading a sheet of text would have an entire page of incredibly strong brightness blasting at them.
This color model continued to be used in the era of 16 color and 256 color workstation environments. In each case, all existing software was written with the expectation that white was the expected color for paper backgrounds. As a result, anyone that produced a new software package that used a darker color for a paper color would appear dingy and unusable on any monitor calibrated for the masses of existing software. It was impossible for software vendors to move away from an old color model, since they would run into visual compatibility problems with old software.
The only way to fix this is to introduce a compatibility mode into graphic display systems (like Xorg and the console framebuffer) where a lower brightness is used for all software that does not flag itself as understanding that it is running on a "full dynamic range" display. Then the monitor brightness may be turned up by, say, 50% (perhaps aided by a software calibration utility displaying patterns on the screen). All old software would have the brightness of its images reduced by the display system by an amount chosen to bring the brightness of 100% white down to the level of a piece of paper. All new software would be allowed to use the "extended" range of colors, with more brightness available. Common interface images and the like would not be extremely bright, but games could have bright explosions.
Images are all currently calibrated for the traditional "white is paper" setting. Image formats would need to be extended to contain a "use extended colorspace" flag, much like PNG contains a gamma setting.
Since this takes some work to implement, and there are two other changes to the workstation color model that need to be made, I would suggest that all three changes should be made at once.
The first additional change is the move to calibrated color systems. Currently, desktops are almost never callibrated to a particular level, unless they are being used by graphic designers. This results in an inability of designers to produce images that may be viewed by end users (if they so desire) at a correct brightness/contrast level. I strongly suspect that this is because even basic color calibration is made difficult (and often expensive) rather than the normal operation that it could be. There is a need for operating system display configuration tools (like the Monitors control panel on Mac OS, the Display control panel on Windows, the Screen Resolution capplet on GNOME, and the KDE Control Center Display tab) to contain a set of callibration images like the ones here to help ensure that the majority of monitors are properly callibrated (again, if the user so desires).
The second additional change is the move to 64-bit color. 64-bit color has been talked about for some time (at least for framebuffer use inside video cards), but hasn't yet caught on. 64-bit color will probably the last color move ever made, as it should pretty much max out the human visual system's ability to distinguish colors. 32-bit color (at least with 8 bits used for each channel) produces banding faintly visible to most people even with a conventional "paper is white" calibration. If you want to see if this affects you, use an image editing program (such as the GIMP) to create a fullscreen gradient, black to white, upper left to lower right, and see if you can see bands of brightness appearing in the image, despite the use of every 256 levels of gray available on your monitor. I can easily see bands (especially in the dark part of the gradient) on my monitor. Moving to a larger dynamic color range will exacerbate this problem if the number bits used for each channel do not incrase, since each brightness level will be further apart. Since apps must be updated to use 64-bit color, the 32-bit to 64-bit transition is an excellent time to introduce a broader range of brightness levels -- one would simply map old 32 bit colors to a range running from, say, 0 to 2^63 (or half of the available brightness range).
By simultaneously adding calibration images to display control panels, increasing the dynamic range, and increasing the bit depth available, end users can be given truly realistic (rather than the equivalent of ink-on-paper) visual reproductions of the outdoors, visually-identical images across workstations, and freedom from banded, perceptibly-imperfect images. There is no reason that users should be able to say "that looks like it's on a computer monitor" -- a computer monitor, properly set up, can properly reproduce everything that is seen in the real world.
As mentioned here, one security problem with passwords is accidently typing one's password into the username field when logging into a system. This can be a problem if the password is being entered in an environment where other people are watching the screen.
Generally, the password field is "masked" in password entry systems to prevent people from reading the entered password -- a character count may be shown with asterisks (as on the Windows login screen or in Red Hat's gdm), visual feedback may be provided as each character is entered (as on the Lotus Notes login screen), or no feedback at all (as on Red Hat's terminal login screen).
It seems that the "accidental password entry in username field" problem could be avoided by also masking the username field.
There would be some issues with such a scheme.
First, it increases the number of characters that must be blindly typed correctly to reach a login. I do not feel that this is likely to be a significant issue, as users type their usernames on a regular basis into the machine.
Second, it eliminates visual feedback that would tell a user that they have the caps-lock key down, a common problem when entering a password.
Third, it prevents people from troubleshooting issues with keyboard configuration (for example, the keyboard may not have the correct layout selected).
I feel that the caps lock problem may be solved in several ways. First, it is possible for many systems to put a visual warning indicator onscreen when the caps lock is on. This may be a good idea, as it is almost never desireable to have caps lock enabled when entering username and password. However, not all systems can detect the state of the caps lock (for instance, when telnetting into a remote machine, caps lock state is not sent to the machine -- breaking this approach when dealing with a remotely-generated password dialog).
Second, it might be possible to print a warning if a username is entered in all capitals.
Third, it might be possible to toggle the masked nature of the username field (possibly through an out-of-band mechanism such as a mouse), or possibly by simply entering a zero-length password and username, or hitting a key on the keyboard that is not reserved for password entry. This way, the vast majority of the time, the username field would be masked, and only unmasked if someone is troubleshooting login problems.
(reprinted from here).
I know of no distros that grant a user ownership of part of the hierarchy beneath their home directory. An example of this would make
Why is this important?
Currently, if a user wants to share files with others (or expose files to a webserver or something), it's required for them to make their home directory world-listable (and the lack of standard ACLs means that they cannot even allow "just the webserver" in, which would still be a breech of security). (They can then create ~/public_html). This is Very Bad from a security standpoint. Because *IX convention dictates that software shall store local config files under $HOME/.programname, this exposes to the entire world what programs a user runs. It also means that if the user stores any files or directories in their home directory, they are world-visible (I dunno if you like everyone with accounts on the machine being able to view your home directory, but I'm not a fan of the idea). Finally, if you're using a umask with any permission bits set for world (as is default on Red Hat and most Linux distros, presumably to facilitate sharing files that have been placed in public directories), it means that everyone can read your files. This is Very Bad. Some sysadmins work around this by scattering a user's files across the system -- creating
ACLs cannot fix this problem, only reduce the egregiousness of it by reducing the number of people that can be poking around in someone's private area.
A better solution (and obviously one that would cause friction for a bit) would be a reworking of the standard *IX directory layout. Here's my take on it:
Default umask shall be 0027, not the current (common on Linux and definitely on RH) of 0022. This makes it a harder to share files (users may hit permission problems by default when dumping things into public_html), and easier to not accidently expose masses of your own files. It's also necessary for the dropbox scheme to work without people accidently sharing masses of files that they didn't intend to.
There are a couple of disadvantages. Users have to chmod o+r files going into the
Oh, yes, and (d) by changing umask to be less permissive, works around a long-standing nasty Linux security hole allowing an attacker to run amok where he shouldn't be in the filesystem. Currently, if an attacker moves into a directory when it's in a directory that he does have access to, and manages to convince a user to move that directory into an area that the attacker shouldn't have traverse access to (like that user's home directory), he is inside that area and can do what he wants until he kills the process in that directory. Since RH's umask is 0002, if an attacker can get into another user's home directory structure, he has access to read through all of their files.
Notes:
* This relies on the Red Hat style private groups scheme, where each user's primary group is a group of the same name as the user.
* I personally think that the *IX convention of dumping config data to ~/.programname should be moved to ~/.config/programname, but that's just me. It'd be faster to access a home directory, and easier to pick out data. Even if the scheme I proposed isn't adopted, this would minimize the number of things in $HOME and reduce the number of things that might inadvertently be set to be world-readable.
FORTUNE'S FUN FACTS TO KNOW AND TELL: A giant panda bear is really a member of the racoon family.
