I've got a stash of Sun keyboards, including the Type 5 I'm using now (attached to a name-brand PC) that I hope will last me until you can no longer use a keyboard with a computer.
There's a significant level of idiocy involved in contorting your hands to reach the mis-placed control key on other keyboards, or lifting your hands away from the keyboard to reach it.
Anyone who fantasizes that the SR-71 was not vulnerable due to its speed or altitude, doesn't understand how much space in that thing was devoted to still-classified ELECTRONICS, in addition to a (for the time) stealthy shape. When your RADAR is telling you that it's miles from where it really is, ground control is going to have your interceptors looking just far enough off to not be able to perform a kill.
MiG-25s have attained 100000 ft, although the practical service ceiling was much less than that, and various SA- were also capable of attaining that altitude and, if vectored correctly, didn't have to "catch" an SR-71, just meet it somewhere with a big explosion.
But the fflush()/fclose()/... only write the stream data to the file system. Neither of them, nor filling the stream buffer, has any semantics to force the file system to actually store the media on disk. fsync(), does, but does not guarantee that the directory structure is flushed.
open() O_SYNC also requires flushing the data to media.
However, forcing the application writer to put in flurries of fflush() or open() files O_SYNC, really does have a nasty effect on file system performance.
150 seconds is simply too long. If we're going to force the application writers to have "magic" knowledge of the underlying kernel/file system/hardware (SSDs), except in the case of embedded systems, then we've defeated the purpose of having an operating system (abstracting those things) in the first place. At the very least, we should have a tuning parameter to put bounds on write latency, but, honestly, right now, the best tuning parameter is to exclude ext4 until it is more robust, or the system designer (which no general-purpose distribution can do) has verified that the potential for data loss is tolerable.
When I write data to a file (either through a descriptor or FILE *), I expect it to be stored on media at the earliest practical moment. That doesn't mean "immediately", but 150 seconds is brain-damaged. Regardless of how many reads are pending, writes must be scheduled, at least in proportion of the overall file system activity, or you might as well run on a ramdisk.
While reading/writing a flurry of small files at application startup is sloppy from a system performance point of view, data loss is not the application developers' fault, it's the file system designers'.
BTW, I write drivers for a living, have tuned SMD drive format for performance, and written microkernels, so this is not a developer's rant.
After the tech support at work spent two hours getting rid of what he could find, I spend another hour in regedit, tracking down the readily visible remainder. I do NOT assume, even after that, that we got all of it. At least, however, nothing is nagging, there are no mysterious processes, and the CPU utilization make sense.
I'll treat your response as one from ignorance, rather than from stupidity or insanity.
#1 it's for a cost-sensitive market, not gamers. USD $0.20 MATTERS, because by the time the costs are multiplied up the distribution chain, it will make a real difference in sales volume. You want to put in the least-expensive hardware that meets the target requirements (with a bit of headroom for last-minute spec changes). No one will see the GUI until after they've bought it, and if the cost delta is too much, they simply won't.
#2 "presentation", simply for the exercise of "presentation", is the equivalent of masturbation, fun for you (presumably), but not for bystanders. "presentation", in the sense that you present the features of the device in either a familiar way, or readily discernible new way, causing the user a minimum of confusion, cognitive dissonance, and frustration is paramount. Once that's accomplished, apply some aesthetic sensibility, but do not degrade the functionality to do it. Requiring, for example, that the user enable hideously insecure Flash, or javascript, for example, to deal with a security device is very nearly a definition of insanity.
Getting yanked around on the front end is not what the discussion is about. NDAs during negotiation are meaningless, because the potential customer knows the quotes from all vendors, and can simply say "lower. no, lower", without specifying anything from the proposal.
This is about telling everyone who will listen that "feature X, though documented, doesn't work; the company denies the problem and isn't fixing it. if it's important to you, don't buy this software.", or, "if you buy this software, the price quote doesn't include the 200% additional cost for \"consultants\" to get it to actually run.".
Idiot-proofing the internet will never work. There seem to be a limitless pool of "better idiots".
Not that it could ever happen, at least in the USofA (see our driving license "requirements"), but letting an internet-connected PC propagate any virus, trojan, worm,... should result in a six months suspension of access to the internet (first offense) and doubling for each subsequent offense. If there is no one in the organization, household,... with the competence to prevent it, hire a "chaffeur", or use "public transport" (yeah, I know, but if Johnny can't do his school projects at the library, perhaps they should be funded so he can).
I am willing to kick in a couple of dollars per month to fund the enforcement.
I remember seeing "A Clockwork Orange", back when, in a cinema near Piccadilly that had many small screens, each seating 30 - 50 (it WAS almost 40 years ago). I thought, then, that it made a lot of sense, and for anything but "Star Wars: Episode IV", or something, I still do.
2048x1080??? That's never going to get me out of the house.
In Microsoft's world, buffer overflows are not always errors. They are also part of deliberate back doors. Classic example is the "we'll execute a correctly-formed MP3" in DX9, which was NOT a buffer overflow, and which was patched in a day when discovered (because they knew exactly where to look). There's no reason, other than a back door, to execute data from a stream. It's a very convenient way to get the DoJ keyloggers, for example, installed.
The back doors are designed in, not purely errors, so all the crackers have to do is find them, and that is why no M$ operating system that is not utterly isolated should ever be considered secure.
Since the Professor Lieury is, apparently, a complete lackwit, maybe he's the one who should play. Perhaps then he'll be able to understand that the games are marketed to adults, not children, and that his own results validate the functionality of the games (exercising the brain on "Brain Age" works just as well as exercising it with other tools).
After all, it's the idiots who elected them that are really at fault.
There are far too many clueless $#%!@ out there fantasizing that making something illegal will somehow prevent it, despite the innumerable counter-examples ("Prohibition", for example).
Upskirters should simply be beaten/stabbed/shot to death on the spot. Pass a law making that legal and see how much longer it continues.
I would love to have a console flight sim on the Wii. Let me use a decent USB flight stick and include a control pad for the other controls (flaps, throttles, gear,...).
I do NOT have "Flight Simulator", because it only runs on M$-Windows, and I use Linux (with a touch of OpenBSD).
In one of the 400-level management classes I took in college, the instructor explained how he had created a test that evaluated for homosexuality, not by the answered themselves, but by the pattern that the location of the answers made on the score sheet. Seemed plausible the way he described it, but whether, or not, the test really could identify gender preference, the testers believed that it could.
His recommendation, "NEVER take such a test", unless preformed by your own shrink, and the scores shared only with you.
The tests are junk science, believed by power-mad paranoid schizophrenics, and you do NOT want to work for them anyway, unless you'll really fit into such a group.
While I don't condone abusing the incompetent, we have been doing our own source code repository backups in engineering, since IT admitted that they cannot recover the repository from backups. We can't recover the repository either, since IT "owns" it, nor are we permitted to use an alternative, but we do incremental and full backups regularly of a "latest" sandbox, and at each release tag, so we can reconstruct the data set.
We have a Linux development environment, but those systems are hobbled by a Windows-centric IT shop that has firewalls blocking access to Google from non-Windows systems and Linux-centric forums everywhere.
This level of incompetence is typical of IT at many small-to-medium (once, even large) places I have worked. Mordac(s), the preventer(s) of information services, work(s) at too many places, and I wouldn't miss them if they all quit and got jobs where they could be useful.
Slashdot Mirror
The original PC keyboard, did, too.
I've got a stash of Sun keyboards, including the Type 5 I'm using now (attached to a name-brand PC) that I hope will last me until you can no longer use a keyboard with a computer.
There's a significant level of idiocy involved in contorting your hands to reach the mis-placed control key on other keyboards, or lifting your hands away from the keyboard to reach it.
At roughly 140,000 lbs, they're still out of reach.
Not after the fuel burns out.
Am I the only one who read the title and had an image of strangling a local ISP executive?
Unfortunately, my "local" ISP choices are Time Warner and AT&T, and, despite the miserable service, their executives are out of my reach.
Anyone who fantasizes that the SR-71 was not vulnerable due to its speed or altitude, doesn't understand how much space in that thing was devoted to still-classified ELECTRONICS, in addition to a (for the time) stealthy shape. When your RADAR is telling you that it's miles from where it really is, ground control is going to have your interceptors looking just far enough off to not be able to perform a kill.
MiG-25s have attained 100000 ft, although the practical service ceiling was much less than that, and various SA- were also capable of attaining that altitude and, if vectored correctly, didn't have to "catch" an SR-71, just meet it somewhere with a big explosion.
Just a shorthand for fwrite()/fflush().
But the fflush()/fclose()/... only write the stream data to the file system. Neither of them, nor filling the stream buffer, has any semantics to force the file system to actually store the media on disk. fsync(), does, but does not guarantee that the directory structure is flushed.
open() O_SYNC also requires flushing the data to media.
However, forcing the application writer to put in flurries of fflush() or open() files O_SYNC, really does have a nasty effect on file system performance.
150 seconds is simply too long. If we're going to force the application writers to have "magic" knowledge of the underlying kernel/file system/hardware (SSDs), except in the case of embedded systems, then we've defeated the purpose of having an operating system (abstracting those things) in the first place. At the very least, we should have a tuning parameter to put bounds on write latency, but, honestly, right now, the best tuning parameter is to exclude ext4 until it is more robust, or the system designer (which no general-purpose distribution can do) has verified that the potential for data loss is tolerable.
When I write data to a file (either through a descriptor or FILE *), I expect it to be stored on media at the earliest practical moment. That doesn't mean "immediately", but 150 seconds is brain-damaged. Regardless of how many reads are pending, writes must be scheduled, at least in proportion of the overall file system activity, or you might as well run on a ramdisk.
While reading/writing a flurry of small files at application startup is sloppy from a system performance point of view, data loss is not the application developers' fault, it's the file system designers'.
BTW, I write drivers for a living, have tuned SMD drive format for performance, and written microkernels, so this is not a developer's rant.
You haven't even come close to removing it.
After the tech support at work spent two hours getting rid of what he could find, I spend another hour in regedit, tracking down the readily visible remainder. I do NOT assume, even after that, that we got all of it. At least, however, nothing is nagging, there are no mysterious processes, and the CPU utilization make sense.
You must be new here.
Sounds a bit like my early Amiga A1000 development system (2 MB A2000 DRAM card added, so plenty of usable storage):
Load work environment from diskette to RAM disk (best RAM disk ever; resized automatically as needed), and switch to it as system disk.
Load the source code from another diskette, and edits/complies were fast checkpoint to diskette, as appropriate.
I'll treat your response as one from ignorance, rather than from stupidity or insanity.
#1 it's for a cost-sensitive market, not gamers. USD $0.20 MATTERS, because by the time the costs are multiplied up the distribution chain, it will make a real difference in sales volume. You want to put in the least-expensive hardware that meets the target requirements (with a bit of headroom for last-minute spec changes). No one will see the GUI until after they've bought it, and if the cost delta is too much, they simply won't.
#2 "presentation", simply for the exercise of "presentation", is the equivalent of masturbation, fun for you (presumably), but not for bystanders. "presentation", in the sense that you present the features of the device in either a familiar way, or readily discernible new way, causing the user a minimum of confusion, cognitive dissonance, and frustration is paramount. Once that's accomplished, apply some aesthetic sensibility, but do not degrade the functionality to do it. Requiring, for example, that the user enable hideously insecure Flash, or javascript, for example, to deal with a security device is very nearly a definition of insanity.
What pferdmerde!
Getting yanked around on the front end is not what the discussion is about. NDAs during negotiation are meaningless, because the potential customer knows the quotes from all vendors, and can simply say "lower. no, lower", without specifying anything from the proposal.
This is about telling everyone who will listen that "feature X, though documented, doesn't work; the company denies the problem and isn't fixing it. if it's important to you, don't buy this software.", or, "if you buy this software, the price quote doesn't include the 200% additional cost for \"consultants\" to get it to actually run.".
Idiot-proofing the internet will never work. There seem to be a limitless pool of "better idiots".
Not that it could ever happen, at least in the USofA (see our driving license "requirements"), but letting an internet-connected PC propagate any virus, trojan, worm, ... should result in a six months suspension of access to the internet (first offense) and doubling for each subsequent offense. If there is no one in the organization, household, ... with the competence to prevent it, hire a "chaffeur", or use "public transport" (yeah, I know, but if Johnny can't do his school projects at the library, perhaps they should be funded so he can).
I am willing to kick in a couple of dollars per month to fund the enforcement.
I remember seeing "A Clockwork Orange", back when, in a cinema near Piccadilly that had many small screens, each seating 30 - 50 (it WAS almost 40 years ago). I thought, then, that it made a lot of sense, and for anything but "Star Wars: Episode IV", or something, I still do.
2048x1080??? That's never going to get me out of the house.
In Microsoft's world, buffer overflows are not always errors. They are also part of deliberate back doors. Classic example is the "we'll execute a correctly-formed MP3" in DX9, which was NOT a buffer overflow, and which was patched in a day when discovered (because they knew exactly where to look). There's no reason, other than a back door, to execute data from a stream. It's a very convenient way to get the DoJ keyloggers, for example, installed.
The back doors are designed in, not purely errors, so all the crackers have to do is find them, and that is why no M$ operating system that is not utterly isolated should ever be considered secure.
http://xkcd.com/327/
Locally, RoadRunner stopped supplying the data back around Thanksgiving 2008.
Turning off a service the device cannot use seems like a good idea.
There's no OFF on my Toshiba DVR, however.
Plus, of course, nearly all of the DRM out there.
I'll buy native games, as I have done in the past, and NOT buy games because they don't play on it.
http://xkcd.com/501/
I would like to get both passport and driver's license covers.
A google has so much noise that I cannot find the signal.
Any links to to something other than mumetal by the sheet?
Since the Professor Lieury is, apparently, a complete lackwit, maybe he's the one who should play. Perhaps then he'll be able to understand that the games are marketed to adults, not children, and that his own results validate the functionality of the games (exercising the brain on "Brain Age" works just as well as exercising it with other tools).
To borrow a phrase "What a maroon!".
After all, it's the idiots who elected them that are really at fault.
There are far too many clueless $#%!@ out there fantasizing that making something illegal will somehow prevent it, despite the innumerable counter-examples ("Prohibition", for example).
Upskirters should simply be beaten/stabbed/shot to death on the spot. Pass a law making that legal and see how much longer it continues.
I would love to have a console flight sim on the Wii. Let me use a decent USB flight stick and include a control pad for the other controls (flaps, throttles, gear, ...).
I do NOT have "Flight Simulator", because it only runs on M$-Windows, and I use Linux (with a touch of OpenBSD).
In one of the 400-level management classes I took in college, the instructor explained how he had created a test that evaluated for homosexuality, not by the answered themselves, but by the pattern that the location of the answers made on the score sheet. Seemed plausible the way he described it, but whether, or not, the test really could identify gender preference, the testers believed that it could.
His recommendation, "NEVER take such a test", unless preformed by your own shrink, and the scores shared only with you.
The tests are junk science, believed by power-mad paranoid schizophrenics, and you do NOT want to work for them anyway, unless you'll really fit into such a group.
While I don't condone abusing the incompetent, we have been doing our own source code repository backups in engineering, since IT admitted that they cannot recover the repository from backups. We can't recover the repository either, since IT "owns" it, nor are we permitted to use an alternative, but we do incremental and full backups regularly of a "latest" sandbox, and at each release tag, so we can reconstruct the data set.
We have a Linux development environment, but those systems are hobbled by a Windows-centric IT shop that has firewalls blocking access to Google from non-Windows systems and Linux-centric forums everywhere.
This level of incompetence is typical of IT at many small-to-medium (once, even large) places I have worked. Mordac(s), the preventer(s) of information services, work(s) at too many places, and I wouldn't miss them if they all quit and got jobs where they could be useful.