NO!!! It is because I have lost too much work when x servers on ms windows crash. There is even the problem of losing the network connection and the state is lost. VNC just works and never breaks.
There is no doubt that some code will be common between both kernels. Since the unix kernel is such a common teaching too, there is no doubt that datastructures will even have the same variable names. Beyond that, data structures that have a common function but use different variable names will look like they were obfuscated.
If this only turns out to be data structures, I will always assume that this is SCO's attempt to steal money from others. If there is non-trivial amounts of code and design involved my opinion of SCO may shift slightly toward the positive.
One thing that I think about is the source code program that SCO offered a few years ago; did they release code and hope that someone would steal it?
What got me was when she said that she did not type very well. I have to question how a writer who needs a computer for her job has gone this long without learning to type.
What you are describing is as simple as having the window manager renice a program when it is brought to the top of the window stack.
The way that would be done on a unix would be a renice daemon so all processes could do a renice. Now remember this is unix, so what is the problem when we give foreground user appps a higher priority? Well there may be any number of users on the system. Thus there could be a large number of processes with increased priority and the system would grind to a stand still.
Sorry you cannot scale simple single user hacks to a multiuser system.
What good is this tarpit if the senders software senses a slowing connection and then the sender starts opening new connections to send mail. The key for the sending software is to maximize bandwidth usage so by knowing the bandwidth and utilization the software could open 1000000 connections (if it is run on FreeBSD).
I do not drive a car by rote; reacting to a dynamic system can never be learned by rote. A poem can be learned by rote. An algorithm can be learned by rote. A route can be learned by rote, but how I react to any of an infinite number of changes on that route cannot be learned by rote.
I could be convinced that intuition is the brain understanding combinations of many things learned by rote. For example, I write poems, and the best description of how that happens is that they flow onto the paper-that is intuition. When I was young, I could not write poems; I had to read hundreds of poems before I could write them. Somehow, my brain came to understand poetry; I think that I learned poetry (the basic structures) by rote, so writing poetry is now intuitive.
Intuition is not random guessing. For example, when we drive, intuition is what keeps us alive. When you see a car stop in front of you, do you have to think about putting your foot on the break? When the road curves do you have to think about turning the car? When you change gears, do you calculate your speed, gear ratio and tire size, vehicle weight, incline, and motor torque curve? My guess is that your intuition dominates your every action. How often is your intuition wrong?
Speaking of fucking oracle. . . we canceled our support contract with oracle this year because every time that we had a problem, we had to solve it. The only time that we could get them on the phone was when it came time to renew our contract.
Abstract languages have been around for a long time. Kernighan calls them little languages, and he has described them several times in his books. The examples of abstract languages appears endless: snobol, awk, troff, tbl, pic, eqn, ampl, . ... When it comes to problems in their domain, I would always rather use a little language.
I started reading about the itanium in 1994. My guess is that intel was working on it before then. I remember the expected release date was 1998, and I was excited by the thought of getting one.
Assuming that crush is a complete language, it can emulate any other language. Thus there is nothing to keep users from writing the standard c libs, by calling the crush libs (just as we call the unix kernel to build c libs now). Now, since unix is written in c, it follows, that there is nothing that unix can do (sendmail, bind, . . . ) that brix can not.
If it takes you ten hours to compile you system from scratch, then you will have to run your source distribution for many years, without making any changes, before it repays you the time that you lost in the initial install. Please get a clue; there is no performance benefit, and you still can not pee for good distance, so get a binary dist.
Slashdot Mirror
NO!!! It is because I have lost too much work when x servers on ms windows crash. There is even the problem of losing the network connection and the state is lost. VNC just works and never breaks.
I have driven high. I know for a fact that weed impairs my ability to drive. I do not need a fucking PHD to understand that.
Why don't more people code in lisp . . . we know that it is better.
There is no doubt that some code will be common between both kernels. Since the unix kernel is such a common teaching too, there is no doubt that datastructures will even have the same variable names. Beyond that, data structures that have a common function but use different variable names will look like they were obfuscated.
If this only turns out to be data structures, I will always assume that this is SCO's attempt to steal money from others. If there is non-trivial amounts of code and design involved my opinion of SCO may shift slightly toward the positive.
One thing that I think about is the source code program that SCO offered a few years ago; did they release code and hope that someone would steal it?
What got me was when she said that she did not type very well. I have to question how a writer who needs a computer for her job has gone this long without learning to type.
What you are describing is as simple as having the window manager renice a program when it is brought to the top of the window stack.
The way that would be done on a unix would be a renice daemon so all processes could do a renice. Now remember this is unix, so what is the problem when we give foreground user appps a higher priority? Well there may be any number of users on the system. Thus there could be a large number of processes with increased priority and the system would grind to a stand still.
Sorry you cannot scale simple single user hacks to a multiuser system.
What good is this tarpit if the senders software senses a slowing connection and then the sender starts opening new connections to send mail. The key for the sending software is to maximize bandwidth usage so by knowing the bandwidth and utilization the software could open 1000000 connections (if it is run on FreeBSD).
Hmm, Kemet electronics must be in the cartel; they have there own mine now.
I do not drive a car by rote; reacting to a dynamic system can never be learned by rote. A poem can be learned by rote. An algorithm can be learned by rote. A route can be learned by rote, but how I react to any of an infinite number of changes on that route cannot be learned by rote.
I could be convinced that intuition is the brain understanding combinations of many things learned by rote. For example, I write poems, and the best description of how that happens is that they flow onto the paper-that is intuition. When I was young, I could not write poems; I had to read hundreds of poems before I could write them. Somehow, my brain came to understand poetry; I think that I learned poetry (the basic structures) by rote, so writing poetry is now intuitive.
Intuition is not random guessing. For example, when we drive, intuition is what keeps us alive. When you see a car stop in front of you, do you have to think about putting your foot on the break? When the road curves do you have to think about turning the car? When you change gears, do you calculate your speed, gear ratio and tire size, vehicle weight, incline, and motor torque curve? My guess is that your intuition dominates your every action. How often is your intuition wrong?
Speaking of fucking oracle. . . we canceled our support contract with oracle this year because every time that we had a problem, we had to solve it. The only time that we could get them on the phone was when it came time to renew our contract.
Abstract languages have been around for a long time. Kernighan calls them little languages, and he has described them several times in his books. The examples of abstract languages appears endless: snobol, awk, troff, tbl, pic, eqn, ampl, . . .. When it comes to problems in their domain, I would always rather use a little language.
I started reading about the itanium in 1994. My guess is that intel was working on it before then. I remember the expected release date was 1998, and I was excited by the thought of getting one.
Hmm, I have the same problem with MS SQL server and 8k rows.
Assuming that crush is a complete language, it can emulate any other language. Thus there is nothing to keep users from writing the standard c libs, by calling the crush libs (just as we call the unix kernel to build c libs now). Now, since unix is written in c, it follows, that there is nothing that unix can do (sendmail, bind, . . . ) that brix can not.
You are the man. That is so cool. I wish that I was as smart as you. I want to be like you. . . .
Is that what you are looking for? I can not think of any other reason that you would want to run a dist that you have to build yourself.
If it takes you ten hours to compile you system from scratch, then you will have to run your source distribution for many years, without making any changes, before it repays you the time that you lost in the initial install. Please get a clue; there is no performance benefit, and you still can not pee for good distance, so get a binary dist.
Dude, the problem is not VIA. The problem is the onboard raid controler. Forget abaout using that cheap onboard raid.
I do not want just a web server, I want a nice scripting language too. The way that I see it, if it is my box, I do not need local security.