Slashdot Mirror
Secretly Monopolizing the CPU Without Being Root
An anonymous reader writes "This year's
Usenix security symposium
includes a
paper
that implements a "cheat" utility, which allows any non-privileged user to
run his/her program, e.g., like so 'cheat 99% program'
thereby insuring that the programs would get 99% of the CPU
cycles, regardless of the presence of any other applications in the
system, and in some cases (like Linux), in a way that keeps the program
invisible from CPU monitoring tools (like 'top'). The utility exclusively
uses standard interfaces and can be trivially implemented by any
beginner non-privileged programmer. Recent efforts to improve the
support for multimedia applications make systems more susceptible to
the attack.
All prevalent operating systems but Mac OS X are vulnerable, though by
this kerneltrap story,
it appears that the new CFS Linux scheduler attempts to address the
problem that were raised by the paper."
I run several websites off of a single host. If I need to login to do maintenance during peak hours, I'm slowed by Apache and MySQL. This would be a nice utility if it were wrapped into SUDO.
I'd rather you do it wrong, than for me to have to do it at all.
For those harboring poisonous grudges against PDFs, the Googlerised HTML version is here.
Ha! I told you Mac OS was more secure. What? Of course I'm not a fanboy! What gave you that idea! Jeez.
The gnome desktop for years has been hiding processes that h0rk the cpu.
Using up 99% of the CPU's easy!
#include
int main(int argc, char *argv[])
{
while (1) {}
return 0;
}
Summation 2
People have been looking for and exploiting *nix vulnerabilities long before Windows was on the scene.
Not quite sure what justifies a paper out of this.
If you check the linux kernel mailing list for Vassili Karpov, you should find test cases that demonstrate this behavior and tools for monitoring actual CPU usage for a variety of platforms, though I notice no mention of any of that in the paper.
See http://www.boblycat.org/~malc/apc/ for the tool and 'invisible CPU hog' test case.
Sanity is a sandbox. I prefer the swings.
Back in my day we called it renice.
Yes, I'm kidding. Please don't post a long reply explaining how renice differs from this cheat thing. It isn't necessary.
Finally, the "sue" command of PC UNIX has been implemented.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
I seem to recall usenet discussions about this circa the time of !uucp!newsglop!..... It seemed the Unix scheduler would let certain IO operations hog the CPU. And if you somehow installed your app as a IO driver or IO completion routine, then your app could hog the CPU. Similarly since day one of Windows soundcards you could set your app to realtime_priority and everything else would suffer. Not exactly smokin' hot off the press.
That isn't likely to happen without a change in attitude due to both starting furthur behind and progressing more slowly. The current malware situation looks like bad SF and a morality tale of what happens when you allow really stupid things to happen (eg. letting arbitrary code embedded in images run - hopefully that person was dismissed from Microsoft).
This year's Usenix security symposium includes a paper that implements a "cheat" utility, which allows any non-privileged user to run his/her program, e.g., like so 'cheat 99% program' thereby insuring that the programs would get 99% of the CPU cycles, regardless of the presence of any other applications in the system, and in some cases (like Linux), in a way that keeps the program invisible from CPU monitoring tools (like 'top').
Next up, a virus which senses bad grammar and punishes you by using 99% of your CPU. Seriously, somewhere a middle school English teacher is crying, and doesn't know why.
Please help metamoderate.
Curious how this works.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
You gun-toting marxist redneck zealot astroturfers make me sick!
I wasn't aware the schedulers for those systems were so deficient !
In my days (yes, I'm an old fart) - the schedulers had basic principles :
- Voluntary yielding led you to get accounted for the time you spent running.
- You could stay in the interactive queue for only a certain amount of time. After some amount of time had passed (a few secs) you were either bumped to non-interactive if you were running (with longer time slices but lower priority) or removed off the scheduler list for good (if the time spent there was idling). They had a special 'idle but interactive' (not eligible for dispatching) queue for that.
- Scheduling a new task restarted a new time slice
That particular scheduler even had a 3 queue system so that if you got accidentally bumped into the non-interactive queue or if your process was semi-interactive you had a better chance of gaining interactive status again. And they had a 'really' not interactive queue for those CPU hogging processes.
Of course this requires the hardware to have a precise timing feature (something with a granularity that is finer than the process interleaving time slice time and ideally in the magnitude of instruction execution). And this scheduler wasn't using time sampling and time quantums.. (but something more like the OSX timer on demand paradigm).
--Ivan
I don't know. I think retractions would screw with everything else. If you make a boneheaded statement (and I've done it more than once myself), it should stand. Otherwise, everyone who responds to correct your misstatement will look insane, and it'd be hard to metamod, because the comments wouldn't necessarily fit the context anymore, etc.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
This is accomplished by sleeping for a fixed amount in between OS clock ticks. The timeline looks like this:
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
We had a user who insisted on abusing the "nice" command, to run his jobs at a higher priority. Pleading and cajoling didn't work, so we decided to get creative.
We changed nice so that whenever this particular user ran it, it lowered his priority by exactly as much as he was attempting to raise it.
He stopped coming to work soon after that. I suppose he had the last laugh though -- NYIT continued to pay him for another six months.
Thad
I love Mondays. On a Monday, anything is possible.
Does it work on Solaris? If so I can run my sparse distributed memory simulator on the comp sci depts main server without waiting hours to get results!
"Good news, everyone!"
Why not leave the post but allow a "retracted" tickbox? Thus at least the owner of the comment can effectively say "I was wrong, boneheaded, whatever" without having to post another comment and wait two minutes to do it? and all that shows up it a one-liner under the comment:
This comment has been retracted by its poster
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
According to the paper, the reason Mac OS X is not vulnerable is that it uses one-shot timers scheduled for exactly when the next event needs to occur, rather than periodic "ticks" with a fixed interval between them. The "tickless idle" feature introduced in Linux 2.6.21 (currently only on x86, I believe) takes the same approach, and very possibly makes Linux immune too.
(Ironically, immediately after discussing OSX's ticklessness, the paper mentions that "the Linux 2.6.16 kernel source tree contains 8,997 occurrences of the tick frequency HZ macro, spanning 3,199 files", to illustrate how difficult it is to take a tick-based kernel and make it tickless. But those kernel hackers went and did it anyway.)
The tickless feature isn't yet implemented on all architectures that Linux supports, though. I think AMD64 support for it is supposed to come in 2.6.23, along with the new CFS scheduler.
That'd be fine, or even cool. It'd deflect the inevitable storm of 500 people saying, "Wrong n00b!" and not reading down far enough to see that you admitted it already, and let the whole discussion move on to more productive things.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
By "retraction", I meant that in the sense that newspapers use the term: the publication of a statement which redacts a previously published statement (e.g. my post in response to my initial post). The fact that Slashdot won't let me post a reply to my own post for a minute means that I sit there hitting "submit" on my one-line, "oops, I meant..." post for a minute. It's just annoying.
The ability to edit one's comments would be nice, but I'd only want to see that kind of feature if you could actually review the edit HISTORY of a comment, which would be a pretty serious change for Slash (the engine that runs Slashdot).
Tick Based Accounting v.s. Time Sliced/Sample Based Billing
(Reminds me of some Zombies Processes I have seen in the past.)
They took too long to publish this. Linux 2.6.21 (released in April) added support for using one-shot timers instead of a periodic tick, so it avoids the problem like OS X does. In addition to resolving this issue, tickless is important for saving power (because the processor can stay in a low-power state for long enough to get substantial benefits compared to the power cost of starting and stopping) and for virtual hosting (where the combined load of the guest OS scheduler ticks is significant on a system with a large number of idle guests). As a side effect, while the accounting didn't change at that point, the pattern a task has to use to fool the accounting became impossible to guess.
The CFS additionally removes the interactivity boost in favor of giving interactive tasks no extra time but rather just quick access to their available time, which is what they really benefit from.
My mother is a gun-toting marxist redneck zealot astroturfer, you insensitive clod!
The creator of this post (Jacob Smith) hereby releases it, and all of his other posts, into the public domain.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
It's a baseball bat.
It doesn't even matter if these CPU-hogging processes can hide from "top" - you should already be making regular rounds of your users, even the ones you haven't caught doing anything wrong. Nobody questions it when you tell them, "You know what you did." Not when you're the one with the bat.
I recently saw a "tickless" option in the kernel config. Would using that solve this problem? I'm not a kernel hacker by any means; knowing enough to run a clean Gentoo with no issues doesn't necessarily imply programming talent.
~Eien no Inori wo Sasagete~ Searching for my Hatsumi...
(reply to self after RTFA)
What 'saved' the Mac OS was its different use of timing triggers. "All" other OS'es use one common steadily ticking clock as a dealer of time slots. This allows the cheat to "skip to the start of the line (queue)" every time it's had its turn.
OTOH, the Mac uses a stack of alarms set to specific points in the future, and polled in order as they occur. So the difference on Mac OS is that there's no skipping the queue, it's rather "there is no queue, we'll call you when it's your turn".
I don't know the details of the OpenBSD scheduler, but it's very likely the same (clock tick) method as used by the rest of the susceptible OS'es.
"Good news, everyone!"
The paper is quite long, so here's a summary (take this with a grain of salt, who wants accurate information should still RTFP):
Most OSes (Linux, Solaris, Windows but not Mac OS X) are tick-based. This means that the kernel is called from hardware periodically (this is the "HZ" value you set in the Linux kernel). Some of them (Linux) simply check which process is running at each tick and compute statistics based on that ("sample-based statistics"). This means that the process running when the tick happens is billed for the entire period of the tick.
Since ticks are typically "long" (typically 1-10 ms on Linux) more than one process may run during this period. In other words, using this approach leads to inaccuracies in the process billing. If all programs "play by the rules" this works quite well on average though.
Next thing: the classic schedulers typically maintain some sort of "priority" value for each process, which decreases whenever the process is running and increases when it's not. This means that a process runs for some time, its priority decreases, and then another process (which hasn't been running for some time) takes over.
You can exploit that by always sleeping when a tick happens and running only in-between ticks. This makes the kernel thinks that your process is never running and give it a high priority. So, when your process wakes up just after a tick happened, it will have a higher priority than most other processes and be given the CPU. If it goes to sleep again just before the next tick, its priority will not be decreased. Your process will (almost) always run when it wants to and the kernel will think that it's (almost) never running and keep its priority high. You win!
Another aspect is that modern kernels (at least Linux and Windows) distinguish between "interactive" (e.g. media players) and "non-interactive" processes. They do so by looking how many times a process goes to sleep voluntarily. An interactive program (such as a media player) will have many voluntary sleeps (e.g. inbetween displaying frames) while a non-interactive program (e.g. a compiler or some number crunching program) will likely never go to sleep voluntarily. The scheduler gives the interactive programs an additional priority boost.
Since the cheating programs go to sleep very often (at every tick) the kernel thinks they're "very interactive", which makes the situation worse.
Some of the analyzed OSes - even if tick-based - do not use sample-based statistics in the kernel but they do use sample-based statistics for scheduling decisions. So the kernel sees that a process is taking more CPU than it should but it will still keep on scheduling it.
Mac OS X is not affected because it has a tickless kernel (e.g. without periodic interrupts). Because of that sample-based statistics don't work and it has to use accurate statistics, which make it unaffected by the bug.
This bug can be exploited to (at least)
- get more CPU than you're supposed to
- hinder other programs in their normal work
- hide malicious programs (such as rootkits) which do work in the background
Here's a list with the OSes (this USED TO BE a nicely formatted table, but the darned Slashdot "lameness filter" forced me to remove much of the nice lines and the "ecode" tag collapses whitespace).
OS, Process statistics, Scheduler decisions, Interactive/non-interactive decision, Affected
Linux, sample, sample, yes, yes
Solaris, accurate, sample, ?, yes
FreeBSD 4BSD, ?, sample, no?, yes
FreeBSD ULE, ?, sample, yes, yes
Windows, accurate, sample, yes, yes
Mac OS X, accurate, accurate, not needed?, yes
I guess that Mac OS X doesn't need a interactive/non-interactive distinction because of its different (tickless) approach. I assume that interactive applications can (implicitly or explicitly) can be recognized as such in a different way. Does anyone have more information on that?
How does tickless Linux compare? What abo
A very simple patch is to issue RDTSC instructions at process restart and blocking syscall to count the cycles actually used. That way the extensive tick-code doesn't need to be modified.
Someone didn't preview and doesn't know how to use < and >.
Also, what's the deal with that empty block in between the "while (1)" and the "{fork ();}"?
Geez, if you're going to critique someone else's code, do a double-check on your own first.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
The point of the paper is that you could have some malware using 99% of your CPU and it wouldn't even show up in top.
Besides the syntax comment the other poster said, it could've also been that the school implemented per-user process limits on the machine. Linux has had this capability for years and years; most people just don't bother setting it, but universities hosting machines for programming students pretty much have to set it for exactly this sort of thing, whether it be accidental or malicious.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Chris Torek gave a presentation at UseNIX about how a constant quantum could result in a process having its CPU usage unaccounted.
His solution was to use a randomized quantum. Not unique per process, but randomized when the kernel starts running each process. That gave you a better accounting of the CPU time (statistics, doncha know :)), but also made this kind of attach much, much harder.
I'm somewhat disappointed that I did not see Chris and Steven's paper referenced in this one. (I believe that the title of that paper was "Randomized Sampling Clock for CPU Utilization Estimation and Code Profiling," for those who care to find it.)
You should pick better examples. That particular problem was caused by Microsoft using a very well known OPEN SOURCE library for handling image functions. It affected many applications (including ones in linux). Now that you know that, are you still advocating that Microsoft should stop having anything to do with open source software? Didn't think so.
Now I have a *Real* job as part of a programming team working with a *mostly* real RDBMS.
you will be in my prayers, brother-in-arms. It's worse than that, I'm a software development major in college, working as an intern consultant. I don't even know VB, but using Real Languages gives me enough to fly by the seat of my pants. The dbase is done by some guy who can no longer be found, writes spaghetti code and has a fondness for loops while doing lookups. It's been 'upgraded' from Access '95, to '97, to 2K, yet I'm not allowed to just drop the thing into SQL Server and use
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
I'm assuming that we're saying that this application can get 99% of the time-slices on an otherwise occupied system, starving other tasks for resources.
We already have that. They're called McAfee Automatic Update and Windows Automatic Update.
God dammit, I hate those things. I turn on my office computer in the morning, and just let it sit for ten minutes because it's otherwise useless. (I turned-off Windows Automatic Update, but McAfee was more than happy to fill its shoes in needless resource hogging.)
Does it make you happy you're so strange?
That might make an interesting sig, actually.
Red Light Green Light.
Your goal is to run as quickly as you can towards me. When I turn and face you and say "Red Light" you must stop moving and if I catch you moving I make you start over from the beginning. When I'm not looking and say "Green Light" you can move again.
In this case, the goal is to cover the greatest total distance instead of just reaching my position; so we could adapt it from running to eating: The "winner" is the one who eats the most and the losers end up hungry.
Democracy Now! - uncensored, anti-establishment news
Apparently windoze uses thread based scheduling, so a program with more threads gets more priority.. I belive that in most Unixes its process based, depending on the thread package implementation, this may or may not work.
M
but in *nix land those vulnerabilites are called features. Demands to change are always met with demands to keep them the same--"how can I keep my code from 1985 running without it!"
This, and the earlier comments about the latest Linux versions becoming tickless are ruining my plans for making a thumbdrive of nifty utilities.
Your ad here. Ask me how!
How about a baseball analogy? You steal bases by running when the ball's not in the air.
A Car analogy? I got nothin.
No weapon in the arsenals of the world is so formidable as the will and moral courage of free men.-Ronald Reagan
We?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Wait. Something's wrong here. Not if you have two cores, it isn't. If two cheating processes each take 99 percent of a core, then their total is 198 percent.
Nothing new here.
I remember seeing this done on the VAX/VMS mainframe back in 1987. In that environment, it simply meant that you kept track of your timeslice and voluntarily gave it up before the scheduler took it away from you. That meant you got put at the top of the run queue, and unless someone else was doing the same thing, you were the next program to run. Voila... 99% CPU for you!
Of course, ordinary users were given a limited amount of CPU time (as well as connect time, disk space, etc), so for the ordinary student, this just meant they used it up in a day or two instead of having a whole month. But then again, for class accounts, they could usually beg for more.
Under unix variants, one could do the same by implementing cpu quotas at the user level. I've seen network packet quotas, and I'm sure someone out there has done cpu quotas along the same lines.
I am advocating that people should know what their applications will do with different inputs. The above example was a mind bogglingly stupid mistake - viewing an image was enough to spread a virus! The added rant by the poster above blaming poor practice on somebody else and making assumptions about myself (why would I want people to use garbage just because it has a good licence?) I consider a fairly lame apology for somebody else's major mistake that completely ignored any sort of security. It allowed arbitrary code from unknown sources that could have been well hidden in elements of nearly any web page to run - security doesn't get much worse than that no matter who does it.
Bravo, sir
Absolutely. In fact I think it should go half a step further. In the interest of civility, using this feature should hide the message from casual viewing. But a single click will still bring up the original so that you can't use slashdot to be a complete ass and then censor yourself after the damage is done :)
This must be the best summary I've ever seen for any FA. That's all I wanted to know.
NEXT!
Who is General Failure and why is he reading my hard disk?
I could swear i have seen this already in windows XP, i work as an It tech so i see a lot of windows systems (pity me?) anywho, i have come across a few systems where task manager shows the CPU pegged at 80-100% but no process in the process list is using it (sorted by CPU time), even the idle process shows 75% or so.. the system is slow as heck so I tend to believe the over all usage stats but it should show "something" using the processor.
I would say (from my hazy memory) that the system suffered from malware too, as after a cleaning of the system it would be gone (the problem).
I don't know for sure if the system was just too busy to report actual process usage or there was something hidden from the task manager so you couldn't kill it, but i have seen this a few times..
Of course not. It shows that OS research work is likely to be done on a Unix of some sort where the source code is available for anaylsis
TFA points out that Windows is just as vulnerable to these cheats as BSD, Linux and Solaris. The cheat works by releasing the CPU just before the end of a time tick there by allowing the whole tick to be charged to whatever task gets the rest of the tick. Windows, like Solaris, has accurate job accounting information available, but choses not to use it for scheduling. In addition, like the Linux 2.6 kernel, Windows will actually artificially raise the priority of a cheating task under the misaprehension that the job is interactive.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
From Wikipedia:
After all, I am strangely colored.
That doesn't help if you can't upgrade to 2.6 on production machines...
How so exactly? Metamoderation shows message sout of context anyhow...
Were that I say, pancakes?
The WMF vulnerability, not the zlib one.
http://outcampaign.org/
TFA points out that Windows is just as vulnerable to these cheats as BSD, Linux and Solaris. The cheat works by releasing the CPU just before the end of a time tick there by allowing the whole tick to be charged to whatever task gets the rest of the tick. Windows, like Solaris, has accurate job accounting information available, but choses not to use it for scheduling. In addition, like the Linux 2.6 kernel, Windows will actually artificially raise the priority of a cheating task under the misaprehension that the job is interactive.
...but this is proof that Vista is more secure. Aero alone will use up most of your resources, therefore, you cant have a program monopolize the CPU more then the host OS. Just more proof those M$ guys know security ;)
If i had one dollar for every brain you dont have, i would have $1.
What I find amusing is that some bunch of morons have modded up the post he is trying to retract. Are all slashdot moderators and posters that stupid or does someone have a brain out there?
(People can mod this up or down for all I care, but please try reading it first)
I dont read
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Just what are the regulated computations that are being talked about?
I heard about the same VAX hack at about the same time. The idea of boosting process priority by synchronizing to the CPU ticks isn't all that new.
Of course, in 1987 Windows was completely immune to this problem. It had non-preemptive cooperative scheduling. :-)
A cattle prod works better than a baseball bat, but locking the users in the tape safe is the only sure way to ensure that they can't steal CPU cycles.
Just "gittin-r-done," day after day.
If you use Solaris, the top replacement "prstat" has a flag -m that enables microstate accounting. This will give you the exact CPU time used, and not an estimate.
If you want to go further, you can use DTrace, which allows you to monitor in detail exactly what is going on. This is also unaffected by any tricks played by the process.
when its time to check what process is running,the program (which is cheating and already knows the time of check)just sleeps.
That way it looks like it never uses cpu.
I'd rather just see people able to post addendums to their comments. Maybe make them free to subscribers and cost a karma point or two otherwise (to prevent people from getting careless and using it as a crutch)
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
The quoted line above comes from your sig. Do you mean, perhaps:
or am I missing something?With "binaries", one would typically mean "multiple binary stars"; perhaps you meant "binary" (system)? OTOH you mention 3 (11 base 2) types of people, so I quite possibly am missing a joke. Unless... unless one should substitute "binary and counting" for "binaries"; this would fully explain that "11" :)
I speak England very best
Your logic is fine. But alas ... reality ....
Vista won't know that the cheating task is stealing cycles. In practice, the program probably can "monopolize the CPU more than the host OS" -- notwithstanding that OS tasks look on the surface to have higher overall priority. Perhaps we should consider the possibility that Vista is more secure against what the user desires to do than against well targeted attacks.
I know that you are being sarcastic, but it's interesting (to me anyway) that 'Knowing Security' and actually building a usable secure system may not be the same thing.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
"Binaries" is plural because there is more than one possible binary encoding. In this case 11 is two. You are in class 00.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Please. Let's clear this up once and for all.
In a group G of n people, there are (2**n)-1 possible distinct types of people, excluding the empty type, as nobody actually is of that type. Given that for any subset S of G you can find or invent something that these guys and gals have in common which is not shared with G\S, this is also the actual number of distinct types. There can be no more, as if S is defined by more than one property, the type consisting of just that property will just be a subtype of S.
Thus, there are 2**n-1 types of people, where n is the number of people.
-Lasse
--
There are (2**n)-1 types of people in the world (where n = the number of people in the world.)
Your assumption on a power of two binary encoding is incorrect, thank you for illustrating my point.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
You surely use words in a non-mathematical way. The only way that "11" means two, is when you work in the unary numeral system with "1" as a chosen symbol. No binary involved whatsoever, so your signature's wordplay is, actually, a misteak.
Thanks for your reply. Even not your intention, you did reply to my question.
I speak England very best
Teenagers:
Start after parents leave, finish before the predicted time they come back.
Cars:
You SPEED when you are in areas without any cops watching.
Baseball:
Steal bases while the pitcher is not looking. diff: pitcher needs to forget what base you were previously on.
Red Light Green Light:
kid playing the sign is the scheduler. diff: being winner would be the one with the most distance traveled (could change game to eating candy.)
Democracy Now! - uncensored, anti-establishment news
What's this then ?
0 00
1 01
2 11
3 10
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I'm afraid the proof of ignorance is in the opposite direction.
http://en.wikipedia.org/wiki/Grey_code
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Actually, only after seeing your other replies to various ACs, I appreciate the fact that I learned about Gray codes from you, and now I grok the "esotericness" of your signature.
In addition, I fully believe your statement (typically, it's an AC who said it, but it's obvious that it's you, and I have a hunch that you thought the other AC was I, which I wasn't if you do think so) that "It's a trap to prick the pompous": yes, your sig was never meant to be funny, now I see that. Of course, I might be wrong, and you might consider your sig a funny trap, but then you wouldn't know "inside jokes" from "jokes", which is possible since for you "reflected binary code" is equivalent to "binary code" (ie it doesn't need prefixing, and who gives a fuck about common use?).
We disagree on the purpose of a signature, and perhaps on whether you got people skills. I know, our virtual co-existence is too short, but you remind me of some people I know who, being very self-centric become very tiresome to others, and typically said others tend to agree as quickly as possible with said some-people in order to get rid of them. I won't pursue this issue any further, feel free to respond as you see fit (that is, if you think I'm intelligent enough to be worth of a reply from you.) Good hunting!
(To world) A feeble attempt at a humorous sig (which is much less cryptic although it also requires some knowledge and minimal processing):
"Dear Paul: please stop spamming us." --The Corinthians
I speak England very best
:)
/. for quite a few years and I enjoy the cut and thrust, which seems to be waning fo late.
It was just a play words to start with but after the responses I've had to it with people pointing out how wrong I am, even insulting me straight away, indignant in their superior knowledge, I kept it on for the fun of it. I've been on
It's even where I learned it myself about gray code. All I had remembered was the encoding I was told about in school in the mid 80s that wasn't powers of two but was 5-3-1-1 0-10 being :
0000 0001 0011 0100 0101 1000 1001 1011 1100 1101 1111
It's not a gray code but it lead me there via discussion.
More interestingly for me, it was invented at Bell-Labs and I'm a Plan 9 user which hails from the same place.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
masterpiece :)
By gum you're right. It's not using the same binary as 99.9% of implementations, but a grey code is nonetheless a binary system, and therefore could be referred to by some as "a binary", or one of the "binaries".
Hence your statement, while wildly misleading, is correct if one interpretation is taken.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife