Re:Get used to it. We're in for a wild ride.
on
Spidergoats
·
· Score: 2
Did I get something wrong here? Because the longer I think about it, the sicker I get...
Don't be ignorant and pick up some books and start reading. A lot of the panic out there is by people that don't understand the science - hell, mutations happen all the time and are part of, and required for, all life.
I'm not sure it's scientific ignorance. I think the concern is that we'll enslave hordes of helpless mammals to act as chemical factories for our own purposes. --
Patrick Doyle
I'm not sure it's such a great way to visualize anything. There is no design information presented in the diagram; just the entire call graph of the program, which you can tell almost as easily from looking at the code.
Any more information in the diagram--its arrangement into concentric circles and radial slices, for instance--was likely added manually (although I'm just guessing here).
Surely there are diagrams which capture the design abstractions of a system better than a call graph? --
Patrick Doyle
If you have 2 CPUs, using an odd number of processes makes it much less likely that each process will stick to one CPU. Each time a process migrates to another CPU, it will lose any cache context it build up (since that's stored in the CPU).
You may be thinking that two of the processes stick to one CPU each, and the third bounces back and forth. In fact, it is more likely that all three of them bounce around.
Run -j4 and it's more likely that each processor can settle onto one CPU, where it will make good use of the cache.
On one CPU, -j2 is often helpful, since it can overlap processing with IO. However, some broken makefiles secretly depend on the order in which a non-parallel-make builds things, so such makefiles will not work with -j2. --
Patrick Doyle
The 4.33 amps is not fixed, Mr. Smarty Pants; it varies with frequency.
You need to use this one: P=CFV^2
P = power
C = capacitance
F = frequency
V^2 = voltage squared
As you can see, power varies linearly with frequency. Actually, it's better than that: at lower frequencies, you can use a lower voltage, so you get a kind of x^3 relationship with frequency.
Having a Linux industry is the best thing to ever happen to Linux. Much more time and money and manpower is going into Linux kernel development and applications than ever before.
Good point. But are you sure this wouldn't come from academia anyway? There is a lot of academic research which is now using Linux as a platform.
Also, the painfully obvious answer to "who cares?" is, those companies and the people who work for them.
I disagree with this one. These companies see an opportunity for profit in free software, so they take advantage of that opportunity. Does the free software community (eg. Linus) now owe them loyalty because of that? Of course not.
So perhaps instead of "who cares?" I should have asked "why should Linus care?"
--
Patrick Doyle
Its a terrible misuse of the C preprocessor that buys you nothing in form, fucntion or clarity.
Well, I guess software practitioners will never agree what makes code "beautiful".
To me, C's for-loop construct, while powerful, is hard to grok except in the simplest cases. The phrase "for_each_thingy" seems to be much clearer than parsing the code and trying to rediscover its intent.
I call it loop abstraction because once you write "for_each_thingy" then it doesn't matter whether the thingys are stored in a linked list, or an array, or are accessed by function calls. Your "unless" example has no such benefits.
Why duplicate the code for accessing thingys all over the place, when you can define it once and reuse it?
I'd like to hear why exactly you think hard-coding the looping mechanism each time is better, aside from C purity arguments and personal insults.
The question is not "is Linus killing Linux?" but rather "is Linus killing the Linux industry?". And I say, who cares? If the big companies can't make a profit from Linux under Linus, they'll either fork it or give up and move on to something else. Either way, who cares? --
Patrick Doyle
Normal motors can apply a lot of force using a relatively weak motor and a gearbox. Can they do the same with this thing? Could they make a small ball that turns quickly, and connect it to a large ball that turns slowly with more force?
Otherwise, the strength of the motor depends entirely on the strength of the magnets, which would limit its usefulness. --
Patrick Doyle
They put switch statements at each call site. If you know you have three subclasses (A, B, and C) then you produce code like this:
switch(type_id){
case A:/* inline A's code here */
case B:/* inline B's code here */
case C:/* inline C's code here */
default:/* Normal jump table thingy here */
}
--
Patrick Doyle
Inlining.
Some compilers, which use languages more amenable to analysis than C++ (ie. almost any other language), are able to inline all those itsy bitsy functions so that you can write code in an OO way and still have good performance.
This one does that and lots of other stuff. It generates some great code.
--
Patrick Doyle
It sounds like it's just that first connection which could be secretly insecure. Subsequent connections announce that they are insecure by warning that the key has changed.
So what should we sshd users do? Sounds like the following would be prudent:
When you have trusted (eg. physical) access to your host machine, put its public key on a floppy and take it with you.
Add that key to the client machine's known_hosts file yourself, thereby skipping that first insecure connection.
Also save a copy of the private key somewhere. Then if you reinstall ssh, you don't have to change keys.
Never make a connection if the key has changed.
Sounds somewhat labour intensive. Can any of this be automated? If you have several hosts, can you safely use the same key pair for all of them? --
Patrick Doyle
Man, why'd you have to go and spoil a good point by recommending BASIC? There are few languages with such a great capacity to teach bad habits, except perhaps for this one. --
Patrick Doyle
Slashdot Mirror
--
Patrick Doyle
That's the trouble with professions which make things look simple: people tend to think they are simple.
--
Patrick Doyle
Now if you're talking about a printer with 256MB, then that's something...
--
Patrick Doyle
I'm not sure it's such a great way to visualize anything. There is no design information presented in the diagram; just the entire call graph of the program, which you can tell almost as easily from looking at the code.
Any more information in the diagram--its arrangement into concentric circles and radial slices, for instance--was likely added manually (although I'm just guessing here).
Surely there are diagrams which capture the design abstractions of a system better than a call graph?
--
Patrick Doyle
They weren't worried about boats bumping into the car, dude.
--
Patrick Doyle
I stand corrected.
--
Patrick Doyle
Maybe "10 times more" means 1000% more, which means is 11 times as much. (Ok, that's a stretch.)
--
Patrick Doyle
If you don't give -j2 on the command line, how do you suppose it would get in there?
--
Patrick Doyle
If you have 2 CPUs, using an odd number of processes makes it much less likely that each process will stick to one CPU. Each time a process migrates to another CPU, it will lose any cache context it build up (since that's stored in the CPU).
You may be thinking that two of the processes stick to one CPU each, and the third bounces back and forth. In fact, it is more likely that all three of them bounce around.
Run -j4 and it's more likely that each processor can settle onto one CPU, where it will make good use of the cache.
On one CPU, -j2 is often helpful, since it can overlap processing with IO. However, some broken makefiles secretly depend on the order in which a non-parallel-make builds things, so such makefiles will not work with -j2.
--
Patrick Doyle
Imagine how fast a JVM could be on a chip with so much JIT support?
--
Patrick Doyle
The 4.33 amps is not fixed, Mr. Smarty Pants; it varies with frequency.
You need to use this one: P=CFV^2
P = power
C = capacitance
F = frequency
V^2 = voltage squared
As you can see, power varies linearly with frequency. Actually, it's better than that: at lower frequencies, you can use a lower voltage, so you get a kind of x^3 relationship with frequency.
--
Patrick Doyle
Don't be expecting The Matrix here--there is no interpolation, so the turning is very jerky--but I think this shows promise.
--
Patrick Doyle
Earthquake? Last week an entire star system was swallowed by the black hole at the center of our galaxy.
Yeah, it's not worth thinking about unless it's absolutely the biggest tragedy in the whole world.
--
Patrick Doyle
Good point. But are you sure this wouldn't come from academia anyway? There is a lot of academic research which is now using Linux as a platform.
Also, the painfully obvious answer to "who cares?" is, those companies and the people who work for them.
I disagree with this one. These companies see an opportunity for profit in free software, so they take advantage of that opportunity. Does the free software community (eg. Linus) now owe them loyalty because of that? Of course not.
So perhaps instead of "who cares?" I should have asked "why should Linus care?"
--
Patrick Doyle
Its a terrible misuse of the C preprocessor that buys you nothing in form, fucntion or clarity.
Well, I guess software practitioners will never agree what makes code "beautiful".
To me, C's for-loop construct, while powerful, is hard to grok except in the simplest cases. The phrase "for_each_thingy" seems to be much clearer than parsing the code and trying to rediscover its intent.
I call it loop abstraction because once you write "for_each_thingy" then it doesn't matter whether the thingys are stored in a linked list, or an array, or are accessed by function calls. Your "unless" example has no such benefits.
Why duplicate the code for accessing thingys all over the place, when you can define it once and reuse it?
I'd like to hear why exactly you think hard-coding the looping mechanism each time is better, aside from C purity arguments and personal insults.
--
Patrick Doyle
The question is not "is Linus killing Linux?" but rather "is Linus killing the Linux industry?". And I say, who cares? If the big companies can't make a profit from Linux under Linus, they'll either fork it or give up and move on to something else. Either way, who cares?
--
Patrick Doyle
#define for_each_thingy(current, list) for(current=list->head; current; current=current->next)
Then you get to write code like this:
void print_thingy_list(Thingy_list list){ /* Wow, nice and abstract. */
Thingy *t;
for_each_thingy(t, list){
print(t);
}
}
--
Patrick Doyle
Normal motors can apply a lot of force using a relatively weak motor and a gearbox. Can they do the same with this thing? Could they make a small ball that turns quickly, and connect it to a large ball that turns slowly with more force?
Otherwise, the strength of the motor depends entirely on the strength of the magnets, which would limit its usefulness.
--
Patrick Doyle
They put switch statements at each call site. If you know you have three subclasses (A, B, and C) then you produce code like this: /* inline A's code here */
/* inline B's code here */
/* inline C's code here */
/* Normal jump table thingy here */
switch(type_id){
case A:
case B:
case C:
default:
}
--
Patrick Doyle
This one does that and lots of other stuff. It generates some great code.
--
Patrick Doyle
For $98 Canadian (about $65 US) I bought a Duron 700 which I now have running quite happily at 1GHz. How's that for value?
--
Patrick Doyle
Boot messages aren't so great anyway. Wouldn't you rather have a concise report of what's working and what's not working?
--
Patrick Doyle
So what should we sshd users do? Sounds like the following would be prudent:
-
When you have trusted (eg. physical) access to your host machine, put its public key on a floppy and take it with you.
-
Add that key to the client machine's known_hosts file yourself, thereby skipping that first insecure connection.
-
Also save a copy of the private key somewhere. Then if you reinstall ssh, you don't have to change keys.
-
Never make a connection if the key has changed.
Sounds somewhat labour intensive. Can any of this be automated? If you have several hosts, can you safely use the same key pair for all of them?--
Patrick Doyle
Man, why'd you have to go and spoil a good point by recommending BASIC? There are few languages with such a great capacity to teach bad habits, except perhaps for this one.
--
Patrick Doyle
This is my favourite quote:
We can now write device drivers in perl, and let them run on the iMAC across the hall from you.
--
Patrick Doyle