Except that cell phone already have to remain on all the time to function.
And they get the time for free when they talk to the tower, which they already must do to function. And have to keep track of the time to known when to talk to the tower.
And they have to have a display functioning when open. Although it would be nice to be able to turn the non-flip phone's display off when the keyboard is locked.
Now, yes, there are some stupid cells which keep track of the time even when off, thus sucking batteries, but many do not. Mine just get it from the tower when it gets turned on.
Cell phones would save no energy at all by not being able to tell us the time. I guess you can argue they waste energy by printing the time on the screen when we sometimes don't need it, but the power useage of an LCD is almost nill, and it's only when the screen is updated. Popping open the list of names and paging though it once takes as much power as displaying the time for several hours, assuming the phone actually updates the screen while closed, which is probably not true.
And ten seconds of backlight uses a hundred times that much power.
VCRs and coffee makers are different. One, they usually aren't waiting for any specific time. And two, they have to run a whole AC/DC conversion thing to get the right voltage to run the LED light and run the circuit board. This is actually where a lot of waste energy goes.
However, the actual VCR clocks don't bother me, mainly because you actually need a damn clock at your TV, because, duh, things are scheduled at certain times. Assuming it wasn't designed by an idiot and sucks huge amounts of power.
But a coffee maker clock would annoying me, much like my microwave clock annoys me, if I had a coffee maker.
Right now, I want a bill in Congress that fines stupid-ass companies that have off indicators. It's bad enough we have to put up with on indicators, but ones that say 'I'm off' are about as stupid as they come.
Many people aren't quite up on the 'AJAX plug in' stuff yet. If you think AJAX is too complicated, go look at 'xajax', which is PHP. It writes all the Javascript for you.
You literally write 6 lines of PHP, put a div with an id attribute in a page, put a single 'onclick=' on a button, and that button will go back to the server, execute whatever PHP you want, including a PHP function to replace the inside of that div, and transparently update the page. It really is that simple.
And that's just the first library I looked at. For all I know, that's overly-complicated. But in about one minute, I was able to write an example web page that, whenever I clicked a button, it ran some php code to get the server time, and add a line to the page with it.
Without, and this is really the most important part, me ever seeing a line of Javascript except a single function call in the onclick= handler. Which is good, because I hate trying to write cross-platform Javascript.
You can put the PHP in the page, or have an external handler. (When this AJAX catches on, we're going to have to set up seperate virtual servers so it doesn't screw up the logs.;) )
And if you love Javascript, you can do it in the other direction...you can call javascript from the PHP. Technically, you could even bounce back and forth forever, although that is obviously extremely stupid.
Yes, that actually was an innovation...except that it required all sort of proprietary stuff.
As the major advantage of 'AJAX' is that doesn't need that stuff, I guess you could say they invented AJAX...except for the actually useful part of it working cross-platform and transparently. Because of this rather obvious limitation, it failed to actually be used anywhere except intranets.
Part of this wasn't MS's fault, as it was pre-standard DOM, IIRC.
Any idiot can create interesting web technology that operates within a single browser. The power of AJAX is that libraries let it transparently Just Work, to steal an MS slogan.
And once Javascript got standardized enough that you could replace parts of the webpage live, on any browser (Giving us dHTML), the 'And we can edit the page with data from the server' is not an incredibly large conceptual leap. All major browsers, at that point, had some sort of XML parsing support inside their Javascript, so the obvious idea that you give out the same XML to any client, and rely on their Javascript to parse it, was also rather obvious.
In sort, I don't think AJAX really was any sort of innovation. It's just cross-platform DHTML with an XML data channel. Pretending MS invented it five years ago is ignoring the 'cross-platform dHTML' part.
MS throws their own parties. They are amazing parties. They have amazing buffets, they have live music, they spend a lot of money on large dance halls. Their parties are the coolest parties you could ever imagine.
Their parties rock.
At some point, other people will throw parties. Often way after MS had their party. They're liable to be held in empty warehouses. There is no food. There rarely is booze. These parties aren't as cool as MS's, with the singular exception of some recent ones by Google.
But usually these parties suck.
Why does no one ever come to MS's party?
Because MS cards people to make sure they are exactly 21 years old, wearing a striped (diagonally, not those weird hippy vertical ones) tie, and paying a six thousand dollar entrance fee.
The other parties, however, are free. And recently a group of people called OSS has taken to magically pulling food and booze out of thin air and bringing it, for free, to everyone else's party. (And often, to MS's party.)
If the other parties do rock, and the law of averages would indicate that some most, MS wanders in when they're about halfway done, carrying food and booze, sometimes charging for it, although not if the OSS people have already shown up.
People who use AJAX to impliment any sort of navigation are fools. I've heard of people using it like frames, where there's a menu and the main content changes. These people should be shot...they exchanged the slight inconvience of a page refresh for broken navigation include non-bookmarkablity, needless reliance on javascript, and extra server and client load. (Running javascript on the client and non-caching on the server.)
There are exactly three ways AJAX should be used:
Changes that do not matter, like lists populating with shipping costs when you type in your address. No one needs or wants to 'go back' there...they just type another address. Or like dragging the boxes around on Google's personal homepage thingy, that is obviously undoable just by dragging the stuff back. Include 'saving halfway-done forms' and 'verifying forms server-side before a submit' in this.
Or they should be database frontends, which, like it or not, a large percentage of web pages are. You already can't 'go back' in those, and at least AJAX will return some logical result instead of either returing an out-of-date page or a message about 'resubmitting form data' that no user understands. (I'm in the middle of considering converting a rather simple one of these using xajax.)
Or, last but not least, 'live updates' to web pages. Like new forum messages showing up every ten seconds or so, or webmail. In which case the page must give exactly the same 'new' page if someone were to just hit refresh. This is essentually the same thing as a Javascript refresh in the header, and a lot less annoying.
Any other ideas anyone has for AJAX are probably bad ones. Forms updating automatically, database applications where browser navigation already doesn't work right, and live updates to the newest version of a webpage, that's about it.
Although now that I've said that, I know I've missed at least one useful concept.
How I format my playlist tree in foobar2000:
$if2(%va artist%,%artist%)|$substr(%_path%,10,$strrchr(%_pa th%,/))|%album%|%title%
Sorts by artists, grabs the last directory path if they're in a subdirectory (My music is in h:\music\artist or h:\music\misc, and the 10 gets rid of those slashes. Then it sorts on any subdirectories left over), then by album, and shows each title.
And that's just the sorting. You can do very complicated queries before it gets to that point.
Wherver I click in the tree, I get that replacing my main playlist. I can double click and get a more permanant one, or even middle click and get a 'forever' playlist named after that spot in the tree.
Sadly, foo_playlist_tree is still fairly beta. Although there are other way to do similar things.
You're getting a bit out there. But 'People do not have the right to accumulate the planet's resources excessively (just look at all the rich people who suck up land and use it for completely stupid shit that has no long term investment value or social value whatsoever).' is basically what I was going for.
I think it's absurd that people can claim ownership of vast tracts of land and say 'Pay me money to live here'. They didn't build the land. They might have improved it, and certainly credit should be given for that.
But, basically, the whole system of land ownership is broken, and in many places it has devolved into feudalism. I think a way around this would be to raise taxes on more than X amount of land. You get 10 acres at normal tax rate, and anything over that is quadruple. This is just off the top of my head. Businesses would need some formula based on how many people work there and how what they do, or posibly you could make some distinction between land owned to run the business, and land owned for investment.
Which is really what I'm attacking here. Land owned for investment. If it was any other necessity except land they were purchasing, we'd call it 'hoarding'. I don't really have a problem with people who own 100 acres and use them, I have a problem with people who own 100 arces, use 25 of them, lease the other 75 of them, and live off the money. What, exactly, are they contributing there? What was their original contribution there?
Oh, and don't give me that 'they took the risk' crap. Land won't magically vanish if no one 'takes the risk'. It may, indeed, be a risk to purchase land, but it's a risk that can only help or harm the purchasers, unlike starting a business, which hopefully helps everyone by producing things.
Land is, in fact, the original 'intellectual property'. You can own a shirt, you can own a car, you can even own a house. You can own anything that you made, or bartered for with the person who made it. You can even own things that you didn't make but were hard to pull out of the earth, like iron ore.
You can't own land, unless you've figured out a way to barter with whoever Created it. Land just is. We need some way to say 'Hey, I'm using this land here', and it should apply even when we aren't in possession of it, like our car is still our car even if it's out of sight. We've decided to use 'ownership', which was created as a means to keep control of physical items.
It seemed to fit, and all was good until the feudalism was invented. And even with the fall of feudalism, the practice of 'owning' large amounts of land and letting people who use 'your' land pay you money has continued.
OTOH, many of the solutions to this problem have been as bad as the original problem. Price controls on apartments, for example. It's all well and good to say 'You cannot raise the lease of this land over X'. It's another to say 'And you must perform building maintance and all other require apartment services within that price'. And the prices are set so low it is hard to keep within that limit, which has resulted in some buildings being converted to condos, which is a good thing, but has also left many buildings standing empty.
Zoning laws are evil only if you accept the idea of land ownership.
Many people have rather fundamental problems with the idea land can be owned. Land ownership is theft. It's a way for rich people to collect taxes from poor people.
I don't agree with the recommendations in that article.
In particular, a spinwait for a resource is about the stupidist thing you can do in a multithreaded app. If you're on a single processor system, you're just wasting time...the lock can't clear until the thread holding it gets time to execute. Thus a spinwait will never lock faster than just trying to grab the mutex.
Maybe in some magical universe where everyone was on hyperthreaded CPUs and always ran exactly one process with three threads, sure, the advice would make sense. No sense in swapping out a thread. However, even pretending we all have mutli-CPUs systems here, 99% of the time, we'd actually like to use our fancy new CPUs to actually be doing work instead of having the processor spin in place so one app looks responses faster at the expense of anything else ever getting a CPU slice. (Hey, if your app starts hogging the CPU, won't it get less slices anyway?)
And if your OS is swapping in and out threads too rapidly, the correct thing to do is not to force it to run your thread longer. That's idiotic. The correct thing to do is to adjust the timeslices.
There's plenty of good advice out there about managing resources in multithreading apps. This is not it.
It waits for many different events, including passed messages.
Look at QS_SENDMESSAGE. That's how threads talk to each other.
But, more importantly, without MsgWaitForMultipleObjects (And other ways of doing the same thing.), you cannot have mutexes. You cannot say 'Wait for this resource to become free, so I can lock it', which is a fundamental part of writing multithreaded programs. Look at CreateMutex, it's right there on the screen. There's a reason all those topics are together.
The message queue is an incredibly important part of any Windows program. It is, indeed, how the GUI talks to the program, and it's how everything else talks to it, also. You need it without the GUI. You don't even know when to exit without it, because nothing could tell you to exit.
And Linux sets up something similiar on every program, called a signal handler. For multithreaded programs, it requires more, and for X programs, it requires yet more.
So this is a red herring when talking about speed of starting processes and threads. Windows has a unified message queue, and setting it up is logically a lot easier than the silliness on Linux.
You know, that raises another interesting question besides 'How'd he patent something in violation of physics?
Namely, how'd he patent something that'd been clearly explained in various 'Physics of Star Trek' books over the last decade?
Of course, Star Trek didn't invent the idea of bending space to go FTL. It's just the best known for a 'warp drive'.
There are basically only four basic ways to go faster than light that stand up to any physics scrutiny at all: Hyperspace(1), going into another dimension where C is higher or space is smaller; bending our space, via wormholes(2) or making space in front of you smaller and behind you bigger(3); and teleportation, by swapping out two chunks of spacetime(4), or by making all the particles in your body appear elsewhere via quantum teleportation(5); quantum entanglement, which doesn't actually move anything FTL, it destroys it in one place and instantly recreates it elsewhere(6) (This is actually what people are talking about when they speak of quantum teleportation)
Any of these might require you changing form, like to energy, first, but I'm talking about the actual 'FTL' part.
Those are really the only ways we've ever come up with. I'm sure we'll invent more forms of the ways, but anyone with a basic grounding physics could come up with the ones we have. Allowing someone to patent a form of the second is idiotic.
1) B5
2) Andromeda. Stargate, after turning you into energy. Note that Stargate also has (1) for ships
3) Star Trek (ST beaming, incidentally, is not FTL)
4) The new Battlestar Galactica
5) This one is Not Bloody Likely and hence nothing uses it. Quantum teleportation happens at the scale of electrons tunneling through atoms, not people leaping across lightyears.
6) The 'teleporter' in Andromeda's episode 'Banks of the Lethe'. Ironically only works in one region of space so functions more as a time machine than as an FTL drive.
I think a more accurate name might be 'complete wackjobs' community.
These are the people who always think there is some magical free energy out there, and there's a huge government conspiracy to cover it up. This explains how their devices always fail to work, and why no corporation has decided to make 'over-unity' devices. (Aka, pepetual motion machines.)
They are the 'intelligence design' version of physics. They propose something, claim it works, can't demonstrate it, eventually have to admit it's a failure, but luckily they have this new and improved thing... It's exactly the same as ID. It's not science, it's crappy engineering combined with sci-fi, a bad understanding of physics, and a lot of wishing.
This guy just don't like this theory because it claims space is a vaccuum which messes up their pet zero-point energy idea. (Yes, I know ZPE could work. In theory. Once we understand quantum physics a hll of a lot better.)
The actual reason this device won't work is that you can't bend damn spacetime without a lot of effort, if it is at all possible.
You can use circumstantial evidence to infer guilt.
What you have apparently failed to notice is that all evidence is 'circumstantial' to some extent. The victim's blood is discovered on the suspect, and that is used to infer the suspect was next to them while they were stabbed.
All evidence infers guilt, and that is how we will continue to prove cases until police, searching the crime scene, stumble upon a piece of 'guilt'.
What is not weighted heavily in court is evidence that could be explained multiple ways. For example, google searches can be done for lots of random reasons. However, combine that with the fact he was the last one to see her and the body was found in the lake and the murder happened outside at the house, or whatever, and there's a murder case.
However, this isn't what happened here. They know he killed his wife. ('Know' as in, are no longer looking for evidence, because they have enough.) What they are attempting to prove now this was premeditated and not an accident or heat of the moment. As evidenced by the fact he was looking for information on how to kill people and hide their bodies, it clearly was premeditated.
MsgWaitForMultipleObjects doesn't have anything to do with the GUI. It is for message passing. Without it, threads couldn't talk to each other! You can't even do mutexes.
It is also how the GUI tells the application about changes, but it's used for a lot of other stuff, especially in a multithreaded app.
And all OSes have 'a set of objects assigned to each thread'. That's how it can tell the state of the things.
And makes records of them elsewhere. Otherwise it couldn't find them.
Pretending Windows does a great deal more work in this regard, or that this hypothetical large amount of work is somehow an 'advantage' for opening Windows,is just a lie. I've written multithreaded console apps in Windows and Linux, I know exactly how much 'work' gets done.
The advantage in opening windows and creating GUI objects on Windows comes from the fact that it is much faster to open windows and create GUI objects, period. This has nothing to do with threads, it is a matter of the architecture...it is simply slower to connect to X and write to the screen.
Re:securing networks
on
Hardening Linux
·
· Score: 3, Insightful
Not having compilers is the STUPIDEST advice ever.
Does the system have Perl?
First you paste a Mime::Base64-running Perl program in, and then you launch it and paste in the Base64 code. Look, you can get binaries on the system from a shell window!
This is what is known as 'security-through-inconvience'.
Windows does not assume all threads have their own GUI. That's just flat wrong, and it would be a damn stupid assumption if it did. 'Hey, this mail client wants a thread to get email, I better give that thread a GUI.' Luckily for everyone, it does not do that.
In fact, it doesn't 'assume' that all processes have their own GUI. It's just that almost all applications link against the GUI library, so it's loaded at start, which is a good thing.
It is, however, perfectly possible to write console apps that are multi-threaded. I've done it.
This is exactly how it works on Linux, too, except the Linux GUI libraries are varied instead of there just being one, and tend to be heavier to load. And they have to talk with X instead of just doing things.
Linux is, in fact, slower at creating windows than Windows. (Technically, it is X that is slower, but that makes no difference.)
This has nothing whatsoever to do with starting another thread or process. Threads and processes (That, is a process that duplicates itself.) almost never have anything to do with new windows.
The only time the speed it takes to create a window matter WRT to process creation speed is when a new application launches...and 'loading into memory' is a billion times slower than either of those, so that's rather moot.
We're talking about an existing process launching another copy of itself or a new thread of execution within itself, and while that may indeed happen when a new window opens, that circumstance is almost negligable compared to all the other times a new thread or process starts and the application continues to keep exactly the same number of windows open.
Slashdot Mirror
What would be ideal is if we'd just start providing 12 volts DC power from one point, and plug in multiple things.
Even if we had to convert it again to 6 volts or whatever, it would be more efficent.
And they get the time for free when they talk to the tower, which they already must do to function. And have to keep track of the time to known when to talk to the tower.
And they have to have a display functioning when open. Although it would be nice to be able to turn the non-flip phone's display off when the keyboard is locked.
Now, yes, there are some stupid cells which keep track of the time even when off, thus sucking batteries, but many do not. Mine just get it from the tower when it gets turned on.
Cell phones would save no energy at all by not being able to tell us the time. I guess you can argue they waste energy by printing the time on the screen when we sometimes don't need it, but the power useage of an LCD is almost nill, and it's only when the screen is updated. Popping open the list of names and paging though it once takes as much power as displaying the time for several hours, assuming the phone actually updates the screen while closed, which is probably not true.
And ten seconds of backlight uses a hundred times that much power.
VCRs and coffee makers are different. One, they usually aren't waiting for any specific time. And two, they have to run a whole AC/DC conversion thing to get the right voltage to run the LED light and run the circuit board. This is actually where a lot of waste energy goes.
However, the actual VCR clocks don't bother me, mainly because you actually need a damn clock at your TV, because, duh, things are scheduled at certain times. Assuming it wasn't designed by an idiot and sucks huge amounts of power.
But a coffee maker clock would annoying me, much like my microwave clock annoys me, if I had a coffee maker.
Right now, I want a bill in Congress that fines stupid-ass companies that have off indicators. It's bad enough we have to put up with on indicators, but ones that say 'I'm off' are about as stupid as they come.
They tells you how much power they need, at most, ever.
You literally write 6 lines of PHP, put a div with an id attribute in a page, put a single 'onclick=' on a button, and that button will go back to the server, execute whatever PHP you want, including a PHP function to replace the inside of that div, and transparently update the page. It really is that simple.
And that's just the first library I looked at. For all I know, that's overly-complicated. But in about one minute, I was able to write an example web page that, whenever I clicked a button, it ran some php code to get the server time, and add a line to the page with it.
Without, and this is really the most important part, me ever seeing a line of Javascript except a single function call in the onclick= handler. Which is good, because I hate trying to write cross-platform Javascript.
You can put the PHP in the page, or have an external handler. (When this AJAX catches on, we're going to have to set up seperate virtual servers so it doesn't screw up the logs.;) )
And if you love Javascript, you can do it in the other direction...you can call javascript from the PHP. Technically, you could even bounce back and forth forever, although that is obviously extremely stupid.
As the major advantage of 'AJAX' is that doesn't need that stuff, I guess you could say they invented AJAX...except for the actually useful part of it working cross-platform and transparently. Because of this rather obvious limitation, it failed to actually be used anywhere except intranets.
Part of this wasn't MS's fault, as it was pre-standard DOM, IIRC.
Any idiot can create interesting web technology that operates within a single browser. The power of AJAX is that libraries let it transparently Just Work, to steal an MS slogan.
And once Javascript got standardized enough that you could replace parts of the webpage live, on any browser (Giving us dHTML), the 'And we can edit the page with data from the server' is not an incredibly large conceptual leap. All major browsers, at that point, had some sort of XML parsing support inside their Javascript, so the obvious idea that you give out the same XML to any client, and rely on their Javascript to parse it, was also rather obvious.
In sort, I don't think AJAX really was any sort of innovation. It's just cross-platform DHTML with an XML data channel. Pretending MS invented it five years ago is ignoring the 'cross-platform dHTML' part.
MS throws their own parties. They are amazing parties. They have amazing buffets, they have live music, they spend a lot of money on large dance halls. Their parties are the coolest parties you could ever imagine.
Their parties rock.
At some point, other people will throw parties. Often way after MS had their party. They're liable to be held in empty warehouses. There is no food. There rarely is booze. These parties aren't as cool as MS's, with the singular exception of some recent ones by Google.
But usually these parties suck.
Why does no one ever come to MS's party?
Because MS cards people to make sure they are exactly 21 years old, wearing a striped (diagonally, not those weird hippy vertical ones) tie, and paying a six thousand dollar entrance fee.
The other parties, however, are free. And recently a group of people called OSS has taken to magically pulling food and booze out of thin air and bringing it, for free, to everyone else's party. (And often, to MS's party.)
If the other parties do rock, and the law of averages would indicate that some most, MS wanders in when they're about halfway done, carrying food and booze, sometimes charging for it, although not if the OSS people have already shown up.
There are exactly three ways AJAX should be used:
Changes that do not matter, like lists populating with shipping costs when you type in your address. No one needs or wants to 'go back' there...they just type another address. Or like dragging the boxes around on Google's personal homepage thingy, that is obviously undoable just by dragging the stuff back. Include 'saving halfway-done forms' and 'verifying forms server-side before a submit' in this.
Or they should be database frontends, which, like it or not, a large percentage of web pages are. You already can't 'go back' in those, and at least AJAX will return some logical result instead of either returing an out-of-date page or a message about 'resubmitting form data' that no user understands. (I'm in the middle of considering converting a rather simple one of these using xajax.)
Or, last but not least, 'live updates' to web pages. Like new forum messages showing up every ten seconds or so, or webmail. In which case the page must give exactly the same 'new' page if someone were to just hit refresh. This is essentually the same thing as a Javascript refresh in the header, and a lot less annoying.
Any other ideas anyone has for AJAX are probably bad ones. Forms updating automatically, database applications where browser navigation already doesn't work right, and live updates to the newest version of a webpage, that's about it.
Although now that I've said that, I know I've missed at least one useful concept.
$if2(%va artist%,%artist%)|$substr(%_path%,10,$strrchr(%_p
Sorts by artists, grabs the last directory path if they're in a subdirectory (My music is in h:\music\artist or h:\music\misc, and the 10 gets rid of those slashes. Then it sorts on any subdirectories left over), then by album, and shows each title.
And that's just the sorting. You can do very complicated queries before it gets to that point.
Wherver I click in the tree, I get that replacing my main playlist. I can double click and get a more permanant one, or even middle click and get a 'forever' playlist named after that spot in the tree.
Sadly, foo_playlist_tree is still fairly beta. Although there are other way to do similar things.
Damn, you're right. How'd I miss that one?
I think it's absurd that people can claim ownership of vast tracts of land and say 'Pay me money to live here'. They didn't build the land. They might have improved it, and certainly credit should be given for that.
But, basically, the whole system of land ownership is broken, and in many places it has devolved into feudalism. I think a way around this would be to raise taxes on more than X amount of land. You get 10 acres at normal tax rate, and anything over that is quadruple. This is just off the top of my head. Businesses would need some formula based on how many people work there and how what they do, or posibly you could make some distinction between land owned to run the business, and land owned for investment.
Which is really what I'm attacking here. Land owned for investment. If it was any other necessity except land they were purchasing, we'd call it 'hoarding'. I don't really have a problem with people who own 100 acres and use them, I have a problem with people who own 100 arces, use 25 of them, lease the other 75 of them, and live off the money. What, exactly, are they contributing there? What was their original contribution there?
Oh, and don't give me that 'they took the risk' crap. Land won't magically vanish if no one 'takes the risk'. It may, indeed, be a risk to purchase land, but it's a risk that can only help or harm the purchasers, unlike starting a business, which hopefully helps everyone by producing things.
Land is, in fact, the original 'intellectual property'. You can own a shirt, you can own a car, you can even own a house. You can own anything that you made, or bartered for with the person who made it. You can even own things that you didn't make but were hard to pull out of the earth, like iron ore.
You can't own land, unless you've figured out a way to barter with whoever Created it. Land just is. We need some way to say 'Hey, I'm using this land here', and it should apply even when we aren't in possession of it, like our car is still our car even if it's out of sight. We've decided to use 'ownership', which was created as a means to keep control of physical items.
It seemed to fit, and all was good until the feudalism was invented. And even with the fall of feudalism, the practice of 'owning' large amounts of land and letting people who use 'your' land pay you money has continued.
OTOH, many of the solutions to this problem have been as bad as the original problem. Price controls on apartments, for example. It's all well and good to say 'You cannot raise the lease of this land over X'. It's another to say 'And you must perform building maintance and all other require apartment services within that price'. And the prices are set so low it is hard to keep within that limit, which has resulted in some buildings being converted to condos, which is a good thing, but has also left many buildings standing empty.
Many people have rather fundamental problems with the idea land can be owned. Land ownership is theft. It's a way for rich people to collect taxes from poor people.
I was being conservative because I just knew people would pop up and say 'My server reboots in two minutes!'. ;)
In particular, a spinwait for a resource is about the stupidist thing you can do in a multithreaded app. If you're on a single processor system, you're just wasting time...the lock can't clear until the thread holding it gets time to execute. Thus a spinwait will never lock faster than just trying to grab the mutex.
Maybe in some magical universe where everyone was on hyperthreaded CPUs and always ran exactly one process with three threads, sure, the advice would make sense. No sense in swapping out a thread. However, even pretending we all have mutli-CPUs systems here, 99% of the time, we'd actually like to use our fancy new CPUs to actually be doing work instead of having the processor spin in place so one app looks responses faster at the expense of anything else ever getting a CPU slice. (Hey, if your app starts hogging the CPU, won't it get less slices anyway?)
And if your OS is swapping in and out threads too rapidly, the correct thing to do is not to force it to run your thread longer. That's idiotic. The correct thing to do is to adjust the timeslices.
There's plenty of good advice out there about managing resources in multithreading apps. This is not it.
It waits for many different events, including passed messages.
Look at QS_SENDMESSAGE. That's how threads talk to each other.
But, more importantly, without MsgWaitForMultipleObjects (And other ways of doing the same thing.), you cannot have mutexes. You cannot say 'Wait for this resource to become free, so I can lock it', which is a fundamental part of writing multithreaded programs. Look at CreateMutex, it's right there on the screen. There's a reason all those topics are together.
The message queue is an incredibly important part of any Windows program. It is, indeed, how the GUI talks to the program, and it's how everything else talks to it, also. You need it without the GUI. You don't even know when to exit without it, because nothing could tell you to exit.
And Linux sets up something similiar on every program, called a signal handler. For multithreaded programs, it requires more, and for X programs, it requires yet more.
So this is a red herring when talking about speed of starting processes and threads. Windows has a unified message queue, and setting it up is logically a lot easier than the silliness on Linux.
Namely, how'd he patent something that'd been clearly explained in various 'Physics of Star Trek' books over the last decade?
Of course, Star Trek didn't invent the idea of bending space to go FTL. It's just the best known for a 'warp drive'.
There are basically only four basic ways to go faster than light that stand up to any physics scrutiny at all: Hyperspace(1), going into another dimension where C is higher or space is smaller; bending our space, via wormholes(2) or making space in front of you smaller and behind you bigger(3); and teleportation, by swapping out two chunks of spacetime(4), or by making all the particles in your body appear elsewhere via quantum teleportation(5); quantum entanglement, which doesn't actually move anything FTL, it destroys it in one place and instantly recreates it elsewhere(6) (This is actually what people are talking about when they speak of quantum teleportation)
Any of these might require you changing form, like to energy, first, but I'm talking about the actual 'FTL' part.
Those are really the only ways we've ever come up with. I'm sure we'll invent more forms of the ways, but anyone with a basic grounding physics could come up with the ones we have. Allowing someone to patent a form of the second is idiotic.
1) B5
2) Andromeda. Stargate, after turning you into energy. Note that Stargate also has (1) for ships
3) Star Trek (ST beaming, incidentally, is not FTL)
4) The new Battlestar Galactica
5) This one is Not Bloody Likely and hence nothing uses it. Quantum teleportation happens at the scale of electrons tunneling through atoms, not people leaping across lightyears.
6) The 'teleporter' in Andromeda's episode 'Banks of the Lethe'. Ironically only works in one region of space so functions more as a time machine than as an FTL drive.
These are the people who always think there is some magical free energy out there, and there's a huge government conspiracy to cover it up. This explains how their devices always fail to work, and why no corporation has decided to make 'over-unity' devices. (Aka, pepetual motion machines.)
They are the 'intelligence design' version of physics. They propose something, claim it works, can't demonstrate it, eventually have to admit it's a failure, but luckily they have this new and improved thing... It's exactly the same as ID. It's not science, it's crappy engineering combined with sci-fi, a bad understanding of physics, and a lot of wishing.
This guy just don't like this theory because it claims space is a vaccuum which messes up their pet zero-point energy idea. (Yes, I know ZPE could work. In theory. Once we understand quantum physics a hll of a lot better.)
The actual reason this device won't work is that you can't bend damn spacetime without a lot of effort, if it is at all possible.
I think I'll just shoot myself now. Or then.
You have to convince them to open the patent office a day earlier and lie about it.
And learn how to violate thermodynamics.
What you have apparently failed to notice is that all evidence is 'circumstantial' to some extent. The victim's blood is discovered on the suspect, and that is used to infer the suspect was next to them while they were stabbed.
All evidence infers guilt, and that is how we will continue to prove cases until police, searching the crime scene, stumble upon a piece of 'guilt'.
What is not weighted heavily in court is evidence that could be explained multiple ways. For example, google searches can be done for lots of random reasons. However, combine that with the fact he was the last one to see her and the body was found in the lake and the murder happened outside at the house, or whatever, and there's a murder case.
However, this isn't what happened here. They know he killed his wife. ('Know' as in, are no longer looking for evidence, because they have enough.) What they are attempting to prove now this was premeditated and not an accident or heat of the moment. As evidenced by the fact he was looking for information on how to kill people and hide their bodies, it clearly was premeditated.
It is also how the GUI tells the application about changes, but it's used for a lot of other stuff, especially in a multithreaded app.
And all OSes have 'a set of objects assigned to each thread'. That's how it can tell the state of the things.
And makes records of them elsewhere. Otherwise it couldn't find them.
Pretending Windows does a great deal more work in this regard, or that this hypothetical large amount of work is somehow an 'advantage' for opening Windows,is just a lie. I've written multithreaded console apps in Windows and Linux, I know exactly how much 'work' gets done.
The advantage in opening windows and creating GUI objects on Windows comes from the fact that it is much faster to open windows and create GUI objects, period. This has nothing to do with threads, it is a matter of the architecture...it is simply slower to connect to X and write to the screen.
Does the system have Perl?
First you paste a Mime::Base64-running Perl program in, and then you launch it and paste in the Base64 code. Look, you can get binaries on the system from a shell window!
This is what is known as 'security-through-inconvience'.
In fact, it doesn't 'assume' that all processes have their own GUI. It's just that almost all applications link against the GUI library, so it's loaded at start, which is a good thing.
It is, however, perfectly possible to write console apps that are multi-threaded. I've done it.
This is exactly how it works on Linux, too, except the Linux GUI libraries are varied instead of there just being one, and tend to be heavier to load. And they have to talk with X instead of just doing things.
Linux is, in fact, slower at creating windows than Windows. (Technically, it is X that is slower, but that makes no difference.)
This has nothing whatsoever to do with starting another thread or process. Threads and processes (That, is a process that duplicates itself.) almost never have anything to do with new windows.
The only time the speed it takes to create a window matter WRT to process creation speed is when a new application launches...and 'loading into memory' is a billion times slower than either of those, so that's rather moot.
We're talking about an existing process launching another copy of itself or a new thread of execution within itself, and while that may indeed happen when a new window opens, that circumstance is almost negligable compared to all the other times a new thread or process starts and the application continues to keep exactly the same number of windows open.