Aside from the fact that I still run a 386, you should know that there is a difference between processor compatibility and processor optimization. Code can be mostly optimized for a Pentium-IV and still run on a 386.
Anyway, do you have any evidence that breaking 386 compatibility would provide any performance benefit?
What a lame bunch of objections. Do you really think the Boeing people haven't thought of these things?
No window seats: what are all those windows for then?
Roller-coaster rides: even if true, which I doubt, why don't they just bank proportionately slower?
Emergency evacuation: what is your point? Why would this be any harder?
New, untested airframe: this is the strangest objection of all. Overlooking your totally bizarre assumption that Boeing will not test these things before delivery, I think the average passenger's reaction will range from complete apathy and/or ignorance to mild fascination.
NP includes P, and therefore says nothing about how hard an algorithm is. What you meant is NP-hard.
Do you know what NP-hard means?
It means there's no known polynomial-time algorithm, which means the best you can do is probably exponential time. It means 24 hours is barely any more helpful than 24 seconds. A factor of 3600 extra time with an NP-hard might allow you to schedule 40 staff instead of 30, but you'd probably need longer than the lifetime of the universe to reach 100, let alone 400.
People don't just avoid NP-hard problems just to be picky. They avoid them because they simply don't work for large problem sizes in any reasonable amount of time.
SCGUI has no built-in "flow control" for widget layouts because it is assumed that the server handles such. The server can convert flow layouts into coordinates, which is what SCGUI uses. This keeps the client (browser) simple and stable. Future versions will be able to return the width of the client screen (or view area) so that server-based screen managers can scale stuff as needed for a particular client.
That is not a good idea at all. Besides being totally contrary to the goal of "latency-friendlyness" when a window is being resized, it also simplifies the client at the expense of every server, which now has to take care of widget positioning, making them less "simple and stable". Furthermore, it seems an odd place to split the responsibilities: the client is in charge of how everything looks, except that it doesn't control where widgets go? Bizarre.
Plus, some widgets are different sizes on different platforms (assuming they will use some native widgets). Does that mean the server not only has to query the client for the window size, but also for the size of each widget, only to then tell the client where all the widgets should go?
This is a poor design decision. The client should handle widget positioning.
Next, McEuen said, his group planned to try a new molecule that can switch between "1" and "0" by changing shape, rather than by losing or gaining an electron. This physical mechanism, used in place of an electronic switch, could have advantages in economy and efficiency.
I don't know if I have ever seen that sentence before.
A VM is basically nothing but a simulator for a machine that doesn't exist. This is qualitatively different from an emulator. While a simulator mostly pretends to do something, an emulator mostly just does it.
For instance, if you were to make a Pentium emulator to run on a 486, then many of the instructions could be executed as-is by the hardware. Most register values could be stored in actual registers. And so on.
As for the strength of 3DES, I have no idea of the relative strengths of the algorithms. I suppose I had just assumed that the ssh people wouldn't have picked a slow algorithm to be the default unless there was a reason.
If blowfish is strong enough, I guess I might as well use that for everything.
I think "forcing good code" means giving Fred Brooks' uber-programmer the ability to establish automatically-enforced rules to keep the lesser programmers in line.
Now, if I could just figure out which kind of programmer I am...
A third kind of bug is harder to put a catchy name on, but it happens when you constantly say "oh, I didn't think of that case" or "I made a change in these six places but forgot that one". These indicate design problems of a fundamental nature. It means your code is cumbersome and inelegant.
Why should XFree86 care how much memory the system has? Any program should use as much memory as it reasonably needs to fulfill the request of the user. If a program uses too much memory, the OS should take care of it somehow. Whatever the OS does, it shouldn't go unresponsive.
I certainly don't want to retrofit every program I've ever written to put a cap on memory usage, just so I don't hurt the poor little OS.
I don't think that people object to Yoda fighting, it was the way in which he fought. Movies have somehow perpetuated the idiotic notion that martial arts is about jumps and flips.
I look at it a different way. The characters in episodes 4-6 sometimes seem impractically fantastic. But just as Episode I explained why R2-D2 is built the way he is (for wheeling around spaceship hulls, not rolling across the desert), similarly this one explained how a 2-foot-tall man could have an advantage nobody else has: end-over-end turns within the space of half a lightsabre.
You give the viewing public (including me) too much credit if you think we'd notice "speed, accuracy and ability to rapidly change his sabre strokes".
Slashdot Mirror
Anyway, do you have any evidence that breaking 386 compatibility would provide any performance benefit?
What a lame bunch of objections. Do you really think the Boeing people haven't thought of these things?
No window seats: what are all those windows for then?
Roller-coaster rides: even if true, which I doubt, why don't they just bank proportionately slower?
Emergency evacuation: what is your point? Why would this be any harder?
New, untested airframe: this is the strangest objection of all. Overlooking your totally bizarre assumption that Boeing will not test these things before delivery, I think the average passenger's reaction will range from complete apathy and/or ignorance to mild fascination.
Thanks for the reply. I guess we'll have to agree to disagree. :-)
The guy in the next seat will have half of this monstrosity in his lap.
NP includes P, and therefore says nothing about how hard an algorithm is. What you meant is NP-hard.
Do you know what NP-hard means?
It means there's no known polynomial-time algorithm, which means the best you can do is probably exponential time. It means 24 hours is barely any more helpful than 24 seconds. A factor of 3600 extra time with an NP-hard might allow you to schedule 40 staff instead of 30, but you'd probably need longer than the lifetime of the universe to reach 100, let alone 400.
People don't just avoid NP-hard problems just to be picky. They avoid them because they simply don't work for large problem sizes in any reasonable amount of time.
Plus, some widgets are different sizes on different platforms (assuming they will use some native widgets). Does that mean the server not only has to query the client for the window size, but also for the size of each widget, only to then tell the client where all the widgets should go?
This is a poor design decision. The client should handle widget positioning.
Try "Word" mode.
I did that sentence in under a minute.
Try adjusting the Dasher options. Set the max bitrate to 4 and check the "Word" box.
Now that's the first credible criticism I have seen so far.
For instance, if you were to make a Pentium emulator to run on a 486, then many of the instructions could be executed as-is by the hardware. Most register values could be stored in actual registers. And so on.
Please read this.
As for the strength of 3DES, I have no idea of the relative strengths of the algorithms. I suppose I had just assumed that the ssh people wouldn't have picked a slow algorithm to be the default unless there was a reason.
If blowfish is strong enough, I guess I might as well use that for everything.
But I only want blowfish for file transfers. 3des is better (I understand) for interactive shell sessions.
What's wrong with an alias?
Do you have a link?
Just remember to use the "blowfish" cypher for large files. It's much faster than the default 3DES.
I use: alias scp="scp -c blowfish-cbc".
Now, if I could just figure out which kind of programmer I am...
A third kind of bug is harder to put a catchy name on, but it happens when you constantly say "oh, I didn't think of that case" or "I made a change in these six places but forgot that one". These indicate design problems of a fundamental nature. It means your code is cumbersome and inelegant.
Was it a job as a copy editor?
The easiest way to guarantee you'll be wrong is to predict that computer advances will cease at some definite time.
Why should XFree86 care how much memory the system has? Any program should use as much memory as it reasonably needs to fulfill the request of the user. If a program uses too much memory, the OS should take care of it somehow. Whatever the OS does, it shouldn't go unresponsive.
I certainly don't want to retrofit every program I've ever written to put a cap on memory usage, just so I don't hurt the poor little OS.
You give the viewing public (including me) too much credit if you think we'd notice "speed, accuracy and ability to rapidly change his sabre strokes".