I'm maxed out on "relationships" here and have pruned all the "non-reciprocal" befriendings off my list. So I'm terribly sorry but I can't reciprocate anyone else befriending me. You're such a lovely audience, we'd like to take you home with us, we'd love to take you home...
If you want to see more of my snarky comments about geeky stuff, political stuff, and my progress returning to school, drop in and check out http://www.msgeek.org/.
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!
It was bound to happen. I have been banned from AC posting a few times before, but this is the first time I have been banned from logged in posting.
Now, I have only one question. How, exactly, is 'excessive bad posting' defined? In my case, for instance, I never post 'badly' while logged in. This leaves the AC posts. These have been, in my opinion, few. I admit that I have sometimes posted AC attempts at first posts
I haven't been keeping an exact record of the number of these posts, but they are certainly not 'excessive'. Not by a long shot. Anyway, it's not like every single one of them has been modded down . Some of them have actually been modded up (This being the latest example thereof).
In short, I'm dumbfounded. These banning tactics are annoying and weird. What am I supposed to do
UPDATE: Now that I think about it, it occurs to me that this ban might well be the result of me posting many comments that are moderated as Funny. Since this gives no Karma, and these comments are often moderated up and down before settling on their final score, perhaps the 'net value' of my moderations is negative, and this somehow triggers a ban. If this is true, then this is yet another reason for the Slashcoders to seriously reconsider the policy of not giving Karma for Funny moderations, which is in my view quite a ridiculous policy anyway. I know for a fact that it has led to a single post ruining the Karma of more than one user here.
Anyway, I'm just rambling here. I wish they would just come out and say what exactly triggered the ban
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.
Sheez, the AC 'Article Text' troll strikes yet again. And with good results (comment at +5, Informative at the moment). What is it with moderators? Why on Earth would anyone bother to mod something up that they haven't read?
I am still a newbie here on slashdot, so I don't have moderation rights (and getting a little tired of waiting for them
Oh well, back to bashing my head against the wall then I suppose
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.
These last two days were really a proof that democracy in the EU is still a remote goal. To have the Council trump the Parliament twice in 2 days, and going flat against the interests of EU's own citizens, is sad.
While the decision that made
So much for the EU governments looking for their people's interests. Do they really believe that the US will give a damn about the privacy of some foreigners??? when on enough recent occasions the US showed their own citizens' privacy is expendable. And sure they'll just go out of their ways to ensure that all this data is never, ever, ever misused. Not now, not in 20 years. Riiiiight!
So, as expected, money talks the loudest in politics. And if it's foreign money
[*] for the record - communist countries in Eastern Europe were supposed to be democratic, too - at least on paper. They did even have the all-prized hallmark of voting. Guess what - it made no difference whom one was voting for, since the results were known from the beginning. And, as the US constantly seems to remind the world, money do count in an election - money dictate how much of an audience a candidate reaches. How many people would vote for a candidate that never had enough funds to make his/her better platform known? Democracy is truly a joke when pushed too far.
(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.
Yay! first flamebait mod! that should teach me to post anything but pro-Apple comments on Apple articles. Why bother, actually - it's bad for one's health to criticize Apple on
Alright - I must be new here, but here goes:
The distinction between comments that get modded as Funny and those that get modded as Offtopic seems to be indistinct at times.
Given the fact that most, if not all comments that are meant to be funny are more or less not exactly on topic, this seems strange. Anyway, to me, a comment is only offtopic if it has nothing at all to do with the story. Humorous comments at least poke fun about something concerning the story. I have even seen successful 'funny' comments that simply choose to make fun of a previous comment while completely deviating from the topic of the story. I have also seen (and *ahem* posted) comments in this vein that have been modded down as Offtopic.
I am not quite why some of these comments go up while others go down. This is one of the great Slashdot mysteries. I think the most likely theory, however, is that people tend to Offopic-mod 'funny' comments that they don't think are that funny. If this is so, I find this inexplicable for a couple of reasons.
The first one is that this is a waste of mod points, in my view. If you don't think something is funny, you should leave it untouched, unless it is somehow offensive or definitely completely Offtopic. You shouldn't waste mod points going after these comments. Are they really that unfunny that they should be resigned to the bottom of the thread?
The second objection is that being modded Offtopic causes the author to lose Karma, which is obviously bad (duh). Couple this with the fact that being modded Funny does NOT give the author any Karma, this basically, well, sucks. This makes people less inclined to post humorous, wacky comments, and can even make people nervous about doing so. I think that something could and should be done about this.
Well, just my two cents worth of gripe
I like this better. No pressure to enable comments, no hassle, nice web interface...in short, a safe place for me to hang my propeller beanie. Yeah it's a long URL. It's not hard to remember, though.
It's no big deal...I haven't gotten a serious email from that account in months. Check the text box for a temporary way of contacting me...I intend to ride herd on that email pretty closely for a couple of months to make sure that anyone whom I recognize who contacts me there can be forwarded to an email I will check on a regular basis.
I think I'm going to take a break from blogging for a little while so that this message has a chance of getting to the people it needs to get to. See you around New Year's.
Oh yeah, here's a little wish for a great 2004 to all my friends out there in Cyberspace.
Excuse me if I'm a little skeptical. Saddam had several doubles, including people who had plastic surgery to look more like him. This could be one of these hapless "doubles" who was rousted out of a hidey-hole, not the genuine article.
I hope, if this guy's identity is proven as being Saddam Hussein, he goes on trial at The World Court at Den Haag. It's not bloody likely...he's prolly going to get a cell at Gitmo and that's the last we'll hear of him. Anyone know what happened to Manuel Noriega?
Update 3:47pm PST: According to CNN.Com, there were indeed DNA tests done on the man found yesterday...they apparently really do have Saddam Hussein.
You knew the job was dangerous when you took it, Fred. -- Superchicken
