Calling on external C functions from Perl is a pain. [...] Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Think very hard about those two statements and then read between the lines.
I'll have to ask [IE general manager] Dean [Hachamovitch] what the hell is going on, I mean, we're not, there's not like some deep secret about what we're doing with IE.
aka:
"We're not doing squat with IE until we work out this Vista debacle."
Facebook may be trying to gain advantage as a universal authentication gateway for public Web applications.
Who WRITES these sentences? There is not an ounce of possibility of Facebook or any other private enterprise becoming a universal anything for anything but their own enterprise.
For instance, Google (not Facebook, but another intrinsically evil company) can try to scheme it all day if they want - but implementers and 3rd parties are not currently in such a sad state as to make deals with the devil without realizing it.
Payment offers rewards to people who do not care about power or exclusivity. Everything you wrote was pretty much spot on.
Unfortunately the assumption that providing "payment" will somehow dilute the desire for power and need for individual spotlight is somewhat flawed. What happens is that said payment is then indirectly used in an attempt to generate influence and other desired negative traits purely for self-recognition.
The fact is, nobody wants to die unremembered - and a good amount also seek attention whilst living.
The general rule is to not rely on your traffic being kept secret if someone can get inside your network. No shit sherlock.
Everyone in this thread already knows that. This is in fact, a non-thread, and a non-article. The only reason we're even here is for the bottlecap flicking competition.
find * -type f -name '*.txt.0' | sort -k1,1 | less & (other related or unrelated commands while waiting for an asynchronous notification from the shell)
Yep - that's how alot of GUI things suck. They don't make people more efficient, they slow things down. Command line work does have a higher initial learning curve, I won't contest that. However, after the initial novice experience is worked through, the interface pays off in far greater efficiency.
Like I said before, not all GUI elements are bad, definitely not. But I think the interface needs to take a step back and possibly relegate itself even more to just window and graphics management. Clicking yes/no/okay/cancel with a mouse everywhere is a WASTE OF TIME.
Yes - that must have everything to do with inefficiency of the CLI and nothing to do with the stampede of mass-market clickety-clackity-push-a-lotta-buttons-burn-a-lotta-cycles-waste-a-lotta-time appeal, right?
I agree that video, images, *and* sound, have benefits in both visual and audible representations of their management. However - they do not represent the singular requirement for managing files. They make up a decent share *in that domain*, which is why I use the GUI folder viewing/thumbnails/etc. options for that particular purpose and the command line for most other things. You don't use a screwdriver to hammer nails do you?
If I still lived in the states, that would be my plate:
Did I mention I prefer C over C++ too? Stick-shift over automatic too, yep.
But here's the real actual reasoning behind such routine:
10 digits on the keyboard are ALWAYS faster than 2 digits on a mouse.
I'm not dissing all use of GUI-related mechanisms, but command line is succinct, direct, and efficient - which is why it has survived for quite a long time now.
Are you saying I should instead be using a window based file manager to drag little "objects" around rather than use "mv", "cp", "rm" and wildcards? That's absurd.
What you're not getting into is that most users know what they want to do before even making use of a mechanism for doing it - which is why a GUI file manager interface slows one down in almost all cases accept the "hmm, think I'll organize my files today" one.
A GUI file manager is not going to tell me what files have ".txt.0" in their name any faster than "ls *.txt.0" will.
The people who claim KDE eats more RAM than GNOME, and even vice-versa, don't know shit about virtual memory systems or memory management in a modern OS.
Cmon guys, "top" is not what you use to determine how much a particular set of applications are consuming, footprint wise.
Paging, shared maps, and libraries - do some research.
In America they urge you to "Buy American". In China they put a gun to your head and tell you to buy Chinese apparently. ...and in America, they buy Chinese. Sad isn't?
A typical O2 sensor is only used during closed loop operation - i.e. part throttle and cruising. During full throttle or heavy load situations the system goes to open loop - which means preset fuel maps.
In addition, an IAT sensor (intake air temp) is also used for biasing the fuel mix based on manifold temperature.
Until we get to the point of using wide-band O2 sensors capable of extremely low latency, we won't be using O2s for anything but emissions and rough grained "tuning."
"We had vacations coming up a few weeks after the race, so we left the cars in Vegas and returned, two weeks later, to investigate the problem. One of our team members downloaded the 14-day trial of ANTS Profiler and we ran it on our car's guidance code. We profiled the memory usage and saw the obstacle list blowing up."
Except a C programmer would have done this before even starting up the car.
"ANTS Profiler helped us fix a problem in minutes that would have taken us weeks to track down. If only we'd thought of it before the competition, we would most likely have finished the entire race and had a chance at the top prize money."
Which is why newer fisher price languages with automatic garbage collecting are bad in the long run - they don't expose the programmer to enough manual intervention such that they take it for granted.
Slashdot Mirror
Look at this, they even get little "medals":
http://en.wikipedia.org/wiki/User:Jayjg
Nice way to setup a vie for virtual power and recognition there, Jimmy.
[...]
Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Think very hard about those two statements and then read between the lines.
Just wait until H-Dog hears about Perl.
...are the same dudes who still piss their beds.
It's a tired extremely antiquated calculator. Get over it already.
I'll have to ask [IE general manager] Dean [Hachamovitch] what the hell is going on, I mean, we're not, there's not like some deep secret about what we're doing with IE.
aka:
"We're not doing squat with IE until we work out this Vista debacle."
Facebook may be trying to gain advantage as a universal authentication gateway for public Web applications.
Who WRITES these sentences? There is not an ounce of possibility of Facebook or any other private enterprise becoming a universal anything for anything but their own enterprise.
For instance, Google (not Facebook, but another intrinsically evil company) can try to scheme it all day if they want - but implementers and 3rd parties are not currently in such a sad state as to make deals with the devil without realizing it.
and then use 10% of their actual capabilities...
Unfortunately the assumption that providing "payment" will somehow dilute the desire for power and need for individual spotlight is somewhat flawed. What happens is that said payment is then indirectly used in an attempt to generate influence and other desired negative traits purely for self-recognition.
The fact is, nobody wants to die unremembered - and a good amount also seek attention whilst living.
"Are you now or have you ever been a member of the Communist Party of the United States?"
HTML can be made into a general application delivery format without disrupting its original role as a document format.
Fuck no.
Everyone in this thread already knows that. This is in fact, a non-thread, and a non-article. The only reason we're even here is for the bottlecap flicking competition.
He couldn't honor the restraining order Deep Blue took out on him.
Cool. But how is that faster than "ls *.txt.0" ?
Also, how do you do this within Vista's explorer:
find * -type f -name '*.txt.0' | sort -k1,1 | less &
(other related or unrelated commands while waiting for an asynchronous notification from the shell)
Yep - that's how alot of GUI things suck. They don't make people more efficient, they slow things down. Command line work does have a higher initial learning curve, I won't contest that. However, after the initial novice experience is worked through, the interface pays off in far greater efficiency.
Like I said before, not all GUI elements are bad, definitely not. But I think the interface needs to take a step back and possibly relegate itself even more to just window and graphics management. Clicking yes/no/okay/cancel with a mouse everywhere is a WASTE OF TIME.
Yes - that must have everything to do with inefficiency of the CLI and nothing to do with the stampede of mass-market clickety-clackity-push-a-lotta-buttons-burn-a-lotta-cycles-waste-a-lotta-time appeal, right?
I agree that video, images, *and* sound, have benefits in both visual and audible representations of their management. However - they do not represent the singular requirement for managing files. They make up a decent share *in that domain*, which is why I use the GUI folder viewing/thumbnails/etc. options for that particular purpose and the command line for most other things. You don't use a screwdriver to hammer nails do you?
If I still lived in the states, that would be my plate:
CMDLINE
Did I mention I prefer C over C++ too? Stick-shift over automatic too, yep.
But here's the real actual reasoning behind such routine:
10 digits on the keyboard are ALWAYS faster than 2 digits on a mouse.
I'm not dissing all use of GUI-related mechanisms, but command line is succinct, direct, and efficient - which is why it has survived for quite a long time now.
Are you saying I should instead be using a window based file manager to drag little "objects" around rather than use "mv", "cp", "rm" and wildcards? That's absurd.
What you're not getting into is that most users know what they want to do before even making use of a mechanism for doing it - which is why a GUI file manager interface slows one down in almost all cases accept the "hmm, think I'll organize my files today" one.
A GUI file manager is not going to tell me what files have ".txt.0" in their name any faster than "ls *.txt.0" will.
The people who claim KDE eats more RAM than GNOME, and even vice-versa, don't know shit about virtual memory systems or memory management in a modern OS.
Cmon guys, "top" is not what you use to determine how much a particular set of applications are consuming, footprint wise.
Paging, shared maps, and libraries - do some research.
I [b]do[/b] most of my file management from a shell prompt - and I use KDE as my environment 100% of the time.
(with 30+ konsole windows)
I never really got it what the draw of anime is, can someone please enlighten me ?
Me neither - but I suspect the 20-dick wielding monster humanoid might have something to do with it.
Would you trust a multi-ton fuel-laden MOVING machine if it's core controller was coded in C or C#?
.
C
Some factual updates though:
A typical O2 sensor is only used during closed loop operation - i.e. part throttle and cruising. During full throttle or heavy load situations the system goes to open loop - which means preset fuel maps.
In addition, an IAT sensor (intake air temp) is also used for biasing the fuel mix based on manifold temperature.
Until we get to the point of using wide-band O2 sensors capable of extremely low latency, we won't be using O2s for anything but emissions and rough grained "tuning."
"We had vacations coming up a few weeks after the race, so we left the cars in Vegas and returned, two weeks later, to investigate the problem. One of our team members downloaded the 14-day trial of ANTS Profiler and we ran it on our car's guidance code. We profiled the memory usage and saw the obstacle list blowing up."
Except a C programmer would have done this before even starting up the car.
"ANTS Profiler helped us fix a problem in minutes that would have taken us weeks to track down. If only we'd thought of it before the competition, we would most likely have finished the entire race and had a chance at the top prize money."
Which is why newer fisher price languages with automatic garbage collecting are bad in the long run - they don't expose the programmer to enough manual intervention such that they take it for granted.
Humans are incredibly prone to complacency.
Well no questions here - it's obvious to me that you've done quite a lot of overclocking in your time...