Thanks for calling me a liar. You should be aware of what that sort of incivility shows about your own social skills and maturity.
It may have to do with reception or even with band used by my company. The worse the reception the lower the battery life. Probably the higher the frequency, the worse the battery life too.
You'll notice that when asked about key loggers they started talking about methods of detection other than signature recognition. Kaspersky even mentioned that he wasn't talking about signature recognition which is the only reliable method.
You can take this as a hint that none of the companies is distributing signatures of the programs that the government uses.
Oops I meant to types something like "He owns a SLVR and never noticed the camera or the headphone jack".
By the way, I want to show my complete contempt for slashdot not allowing users to post corrections without waiting a fucking lifetime between posts. Cowboy Neal can fuck off!
He owns a SLVR and never noticed the phone or the headphone jack, or read a single sentence of the documentation. He never noticed the TV ads for it as a top of the line cool phone/mp3 player/movie player/camera/video recorder. He bought it, put it in his pocket and never looked at it again.
Look how thin the F3 is. Just because it's not a razr doesn't mean it's not too thin to have good battery life.
I have a brand new cheap motorolla flip (don't know the model #). It doesn't have a camera either, but the battery life is shorter than any phone I've had before it. As the phones get smaller the battery life becomes worse and worse.
At my cell phone co, the cheapest phones they have always seem to be nokia. I didn't get the nokia because I needed on that runs the mapquest app.
Does it, for instance, have a model where it wakes up a new thread for each gui message, not waiting for the previous one to finish? That would make even badly written programs responsive, but it would require programmers to put locks on everything and check state on every message.
Utimately it's a version of #1. The Gui blocks if you make the mistake of doing work in the Gui thread!
I've made work around classes to fix that so that it's only a few key strokes in C++ to chain (ie call) a routine that doesn't run in the current (GUI) thread, it runs in a work thread, and to chain back to a completion routine in the gui when its finished.
It works like a charm, and programs can be completely responsive 100% of the time, like BEOS, I suppose. You can be loading a file, and still the menu works and you can move around the subwindows and edit them... And if a window is recalculating, it's still responsive during that - and it redraws the new data, when done.
You have to specifically decide what the program can do and not do while it's calculating, and code that. So there is more work in keeping a program responsive. You have to code for responsiveness.
"assuming you present a fair characterization of the issue"
I simplified it, partially because I didn't remember all of the details. I think they put handles into thread local memory. So when you use an MFC class in place of a handle, it only works from the Gui thread that created that handle.
No doubt they give some official way to work around the blocks they put in. I know that they have some way of letting users fork a subwindow and give it it's own gui thread, apart from the main gui thread. They made it complicated to implement, but the fact is that if you never do work (other than drawing or managing UI elements) in your gui thread, there's no reason to have more than one gui thread. Anyway multiple gui thread still doesn't solve the problem of allowing you to access a window object or its handles from another thread, gui thread or not.
If you make multiple gui threads the Microsoft way you get subwindows that stop responding when there's work instead of getting a whole ap that blocks on work.
It's better to separate the work in it's own threads - then the whole ap is always responsive. And MS made that harder than they should.
On the other hand, I admit that I never bothered to learn Microsoft's horrible Frankenstein C-code version of Smalltalk's (much cleaner) Model, View, Controller gui model since even Smalltalk's MVC is unnecessarily complicated. In any case, 99.999% of Windows software blocks unnecessarily (even Firefox). So I don't think that Microsoft ever created a work around that works as well as mine does.
Once again, they didn't read the article.
on
Attacking Sandboxes
·
· Score: 5, Insightful
The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.
It also said that software has been found that detects when it's attached to a debugger. Big deal, copy protection schemes have been doing that for decades.
The article then goes on to FUD that code that attacks the sand box "must" be coming.
I disagree, see my post above. The Microsoft GUI was specifically (re)designed to discourage multithreading the gui within an application and that destroys responsiveness. It's a matter of gui design and of the design of the threading in the windowing system.
Easy stuff, in a way. I don't know X/Gnome/KDE well enough to know what's right or wrong with them. But Microsoft must have made a deliberate decision that applications programmers can't be trusted with multithreading, and put cruft in their way.
As one commenter mentioned many programmers are bad at writing reliable multithreaded code.
Microsoft realized this early on and put a bunch of barriers into windows (and more so into MFC) that are designed to prevent programmers from even writing multithreaded GUIs.
Let me make this clear. If you call an MFC gui routine from a thread other than the main GUI thread it will return without executing. If you "send" or "post" a message to a control from the wrong thread using the MFC versions of send() and post(), it will return without doing anything. Microsoft used thread local memory to prevent programmers from being able to write multi-threaded GUIs.
I've programmed work-arounds many times with user-messages and created programs that were as responsive as BEOS programs. Understand that the fact that most programs' guis lock up for a few seconds when opening files, etc. is the result of MS' decision to not trust programmers with multithreading the GUI.
I've also worked on multiprocessor, high performance server apps, and I know how obscure multithreaded techniques are, and how small mistakes can make software unreliable. I don't entirely blame MS for preferring reliability to responsiveness, but they are in a position where they could educate rather than restrict, and they chose restricting.
I'm using the free version of Microsoft Office Accounting - they made it free in order to muscle into QuickBooks market (the free version is equivalent to the 90$ version of quickbooks).
Problems so far:
It depends on a version of SQL server it installs as a service (why does it have to run as soon as I power on the machine?) which sometimes (for no reason) balloons up to over a gigabyte of ram use. Also SQL didn't install properly the first time because it refuses to install in a compressed directory - well as easily as they could test that the directory is compressed, they could have made their subdirectory uncompressed. After all they're installing it as a fucking service and that takes admin access.
It has fucking AVERTISEMENTS running in the main window the time. Not only is there no way to turn them off or to rearrange the window so it doesn't take up 100% of the screen real estate, but the system stops for a few minutes retrying on the fucking ADVERTS every time my internet connection goes down. That's right, you can't do any accounting for fucking minutes because their fucking advertisement is more important!
Really, this all seems like a great reason to pay $200 for a good version of Quickbooks. If the free Office Accounting is bad, is there any reason to believe that the other one, say DOESN'T have adverts? Or that it lets you use your screen for things other than a huge menue designed to force you to watch those averts?
My advice if you want to 'just happen' to hear some good live music would be to first leave the country.
By now you have to leave the US if you want to:
1. Listen to live music.
2. Learn to be a musician and make some money on the side playing in a band.
3. Broadcast music over the internet!
How long till people are sued for humming?!!
Fuck them all!!!
Slashdot Mirror
of worms, rootkits and spyware uh snoopware to the masses?
Years ago I found a website (soon taken down) that had snoop recordings taken with "back orifice" (a Windows root-kit).
Ever since that, the first thing I do when I get a laptop is open it up and remove the built in microphone.
No that's not it. In Soviet Russia, you fail hard drive... No. Where's that goatse link?
The article says "one of the major causes of hard disk failure," not "the major causes of hard disk failure."
It seems to me that years ago, slashdot authors did more than dump articles into summaries with reading them first. What happened?
Commence holding your breath. The phone is one month old and has a brand new lithium ion battery.
Thanks for calling me a liar. You should be aware of what that sort of incivility shows about your own social skills and maturity.
It may have to do with reception or even with band used by my company. The worse the reception the lower the battery life. Probably the higher the frequency, the worse the battery life too.
sounds right
You'll notice that when asked about key loggers they started talking about methods of detection other than signature recognition. Kaspersky even mentioned that he wasn't talking about signature recognition which is the only reliable method.
You can take this as a hint that none of the companies is distributing signatures of the programs that the government uses.
But it's not the source, it's the data.
And publishing data or distributing which compromises investigations is probably a felony.
So how would your open source system work? Would you openly publish how to recognize all of the government's spy software?
I guess I actually talk on my phone. I have to charge it two to four times per day.
Oops I meant to types something like "He owns a SLVR and never noticed the camera or the headphone jack". By the way, I want to show my complete contempt for slashdot not allowing users to post corrections without waiting a fucking lifetime between posts. Cowboy Neal can fuck off!
He owns a SLVR and never noticed the phone or the headphone jack, or read a single sentence of the documentation. He never noticed the TV ads for it as a top of the line cool phone/mp3 player/movie player/camera/video recorder. He bought it, put it in his pocket and never looked at it again.
Yes, on the Motorola site is says that the phone has " Extended battery life," but says nothing else.
If it had even middling specs they'd give the specs. They don't.
I stand by my judgment. It's a thin phone and the battery life no doubt sucks.
Look how thin the F3 is. Just because it's not a razr doesn't mean it's not too thin to have good battery life.
I have a brand new cheap motorolla flip (don't know the model #). It doesn't have a camera either, but the battery life is shorter than any phone I've had before it. As the phones get smaller the battery life becomes worse and worse.
At my cell phone co, the cheapest phones they have always seem to be nokia. I didn't get the nokia because I needed on that runs the mapquest app.
Ok, that explains blocking Send messages, but it doesn't explain blocking Post!!!
They sure picked a piss poor way of enforcing the rule. They should have made Post an exception, since Post is what you need to solve the problem.
It's the lag of sending all of your clicks and key strokes to homeland security before displaying them.
Why is Beos more responsive and in what way?
Does it, for instance, have a model where it wakes up a new thread for each gui message, not waiting for the previous one to finish? That would make even badly written programs responsive, but it would require programmers to put locks on everything and check state on every message.
Utimately it's a version of #1. The Gui blocks if you make the mistake of doing work in the Gui thread!
I've made work around classes to fix that so that it's only a few key strokes in C++ to chain (ie call) a routine that doesn't run in the current (GUI) thread, it runs in a work thread, and to chain back to a completion routine in the gui when its finished.
It works like a charm, and programs can be completely responsive 100% of the time, like BEOS, I suppose. You can be loading a file, and still the menu works and you can move around the subwindows and edit them... And if a window is recalculating, it's still responsive during that - and it redraws the new data, when done.
You have to specifically decide what the program can do and not do while it's calculating, and code that. So there is more work in keeping a program responsive. You have to code for responsiveness.
"assuming you present a fair characterization of the issue"
I simplified it, partially because I didn't remember all of the details. I think they put handles into thread local memory. So when you use an MFC class in place of a handle, it only works from the Gui thread that created that handle.
No doubt they give some official way to work around the blocks they put in. I know that they have some way of letting users fork a subwindow and give it it's own gui thread, apart from the main gui thread. They made it complicated to implement, but the fact is that if you never do work (other than drawing or managing UI elements) in your gui thread, there's no reason to have more than one gui thread. Anyway multiple gui thread still doesn't solve the problem of allowing you to access a window object or its handles from another thread, gui thread or not.
If you make multiple gui threads the Microsoft way you get subwindows that stop responding when there's work instead of getting a whole ap that blocks on work.
It's better to separate the work in it's own threads - then the whole ap is always responsive. And MS made that harder than they should.
On the other hand, I admit that I never bothered to learn Microsoft's horrible Frankenstein C-code version of Smalltalk's (much cleaner) Model, View, Controller gui model since even Smalltalk's MVC is unnecessarily complicated. In any case, 99.999% of Windows software blocks unnecessarily (even Firefox). So I don't think that Microsoft ever created a work around that works as well as mine does.
The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.
It also said that software has been found that detects when it's attached to a debugger. Big deal, copy protection schemes have been doing that for decades.
The article then goes on to FUD that code that attacks the sand box "must" be coming.
Oh, it must be coming. Uhuh.
I disagree, see my post above. The Microsoft GUI was specifically (re)designed to discourage multithreading the gui within an application and that destroys responsiveness. It's a matter of gui design and of the design of the threading in the windowing system.
Easy stuff, in a way. I don't know X/Gnome/KDE well enough to know what's right or wrong with them. But Microsoft must have made a deliberate decision that applications programmers can't be trusted with multithreading, and put cruft in their way.
As one commenter mentioned many programmers are bad at writing reliable multithreaded code.
Microsoft realized this early on and put a bunch of barriers into windows (and more so into MFC) that are designed to prevent programmers from even writing multithreaded GUIs.
Let me make this clear. If you call an MFC gui routine from a thread other than the main GUI thread it will return without executing. If you "send" or "post" a message to a control from the wrong thread using the MFC versions of send() and post(), it will return without doing anything. Microsoft used thread local memory to prevent programmers from being able to write multi-threaded GUIs.
I've programmed work-arounds many times with user-messages and created programs that were as responsive as BEOS programs. Understand that the fact that most programs' guis lock up for a few seconds when opening files, etc. is the result of MS' decision to not trust programmers with multithreading the GUI.
I've also worked on multiprocessor, high performance server apps, and I know how obscure multithreaded techniques are, and how small mistakes can make software unreliable. I don't entirely blame MS for preferring reliability to responsiveness, but they are in a position where they could educate rather than restrict, and they chose restricting.
I'm using the free version of Microsoft Office Accounting - they made it free in order to muscle into QuickBooks market (the free version is equivalent to the 90$ version of quickbooks).
Problems so far:
It depends on a version of SQL server it installs as a service (why does it have to run as soon as I power on the machine?) which sometimes (for no reason) balloons up to over a gigabyte of ram use. Also SQL didn't install properly the first time because it refuses to install in a compressed directory - well as easily as they could test that the directory is compressed, they could have made their subdirectory uncompressed. After all they're installing it as a fucking service and that takes admin access.
It has fucking AVERTISEMENTS running in the main window the time. Not only is there no way to turn them off or to rearrange the window so it doesn't take up 100% of the screen real estate, but the system stops for a few minutes retrying on the fucking ADVERTS every time my internet connection goes down. That's right, you can't do any accounting for fucking minutes because their fucking advertisement is more important!
Really, this all seems like a great reason to pay $200 for a good version of Quickbooks. If the free Office Accounting is bad, is there any reason to believe that the other one, say DOESN'T have adverts? Or that it lets you use your screen for things other than a huge menue designed to force you to watch those averts?
mod -1, funny :)
My advice if you want to 'just happen' to hear some good live music would be to first leave the country.
By now you have to leave the US if you want to:
1. Listen to live music.
2. Learn to be a musician and make some money on the side playing in a band.
3. Broadcast music over the internet!
How long till people are sued for humming?!!
Fuck them all!!!