Perhaps The best way to do this is to define some terms.
One term I will define is logical Many interfaces label this a block. This is the minimum amount of addressable data. It is what the kernel sees as the block size of the disk drive, and also used in the drive communication protocols. The file systems also often use them as a sector size, but that is completely independent of the size of a logical block in disk signaling, which is what most kernels view the device in terms of. From this point forward I will call them "logical blocks". Logical blocks are usually 4096 bytes in size.
Flash devices are generally bit readable and bit writable, but only erasable in large blocks, called "physical blocks". In practice the controller can only address them in increments larger than single bit, but smaller than the full physical block size.
The drive maps multiple logical blocks to a single physical block. This can be done in a haphazard fashion, but the simplest way is to map the physical blocks to the number of consecutive logical blocks that they can fit. So in the beginning the disk can be written to directly, since all the physical blocks are blank. If a logical block needs to be changed, just read the other logical blocks from the original physical block, and write the whole thing to an empty block. However, eventually, all physical blocks will have been written to. From this point forward, a physical block must be erased prior to being used.
The trim command tells the disk of any logical blocks no longer in use. If all of the logical blocks in a physical block are not in use, then the drive can erase that physical block when idle, and be ready to use it with no speed degradation. If it tracks which individual logical blocks are not in use, it can also avoid reading them in any future 'read-erase-write' cycle.
If the drive keeps a pool of unused physical blocks around, it can normally avoid the overhead of erasing on a new write, merely reading any logical blocks from the old physical block, and writing everything to a new physical block, and mark the old physical block for erasure while idle.
If a significant pool of empty physical blocks are maintained, then maximum write performance remains possible as long as the amount written at one time is less than the amount of empty physical blocks in the pool. Only when writing too much at once does the pool run out, and erasures occur during writing, causing poor performance.
Thus TRIM is only particularly valuable if the drive has an unreasonably small collection of spare physical blocks, or if the workload writing lots of data (sequential or not) at one time.
Low end drives suffer from the former problem, keeping few if any spare physical blocks around, while higher end drives can maintain optimum write performance at all times, except for large sustained writes.
Whoa! It can go either way an erased flash block is all ones or all zeros, depending on convention. Assuming the (less common) all zero convention, an erased black can have bits set one at a time, but any time a bit must be unset, the block must be erased. The fastest write performance occurs when the block is already erased. The next fastest is when it can be erased, and then just the new data written. The slowest is to read, erase, and the write the whole flash block.
It is entirely permissible and even sensible to the drive to actually erase any block filled with only TRIM'd sectors, although if the flash block has a mix of TRIM'd and non-TRIM'd sectors, it can skip reading the untrimed ones when rewriting.
>if you know C++ you can get a job in a heartbeat. Yea people with real skills are never unemployed.
Even if you can't code, if you understand computers at the electrical, wire, clock, and register level, and understand binary and hex, you'll never be unemployed.
That first part sounds like somebody familiar with RTL level design, using Verilog or VHDL. That is a very specialized level of knowledge. That said there are definitely people with that level of knowledge who are unemployed. If you know computers at that level you inherently know hex and binary. If you did not know binary you would never be able to do any design work, for example.
Now if you mean, will never be unemployed for the long term, a few months at most, I would probably agree with that.
Colleges can help you but are ultimately unnecessary. Everything you need to know is available for free, or nearly so.
True. Colleges do hep though in making sure you have sufficient awareness of the types of information out there, and by what name it is known. I did not learn anything about computers in college that I could not have learned for free, but I did learn several things that I would probably not have learned otherwise, simply because they were not far enough inside my area of interest. Yet, I most definitely have found this new knowledge useful on occasion.
An engineer with any talent is always building something, because they don't have an option. They have to do it or they go crazy. Whether or not there's a monetary reward is secondary to the need to create. You don't need a job to create something an employer would be interested in seeing.
More accurate would be that the engineering is always solving problems, not necessarily building anything. Even what they do build may not be worth showing off to an employer.
Stupid design? I don't know. My logitech keyboard has 2 rows of two in series (phsyical and logical, athough not touching, but seperated by a small amount so microsoft's invention would work here).
The idea is to get a nominal 3V, which is is closer to 2.4 volts under load. However it draws wnough current that two AA cells in series do not last long enough, so they added a second set of two AA cells in parallel to the first set. The result is that the device works fine with only two cells, but with 4 it lasts a much more reasonable time. (This ability to run on only 2 batteries was not a documented feature)
One of Apple's mice also used this type of design, however here it was a documented feature.
I'm reasonably confident that diodes were used in both designs to prevent shorting if batteries were placed backwards.
The sytntax is: NOUN [is] VERB1 NOUN1 ([in order] VERB2 a NOUN2 (for NOUN3))
The verb "is" is implied. this is the Zero copula, although its use in this manner is considered questionable as legal grammar but is common in headlines.
VERB1 is an infinitive, used with the implied "is" to create a future tense (like in he sentence "john is to leave tonight". In some regions, my own included, the alternative construction "is going" + infinitive sounds more natural, but is equivalent.)
NOUN1 is the direct object of VERB1.
([in order] VERB2 a NOUN2 (for NOUN3)) an adverbial clause, of the purpose type, modifying VERB1, and using an implied conjunction of "in order to" (but that two is part of the following verb. It uses an implied subject of "Google".
VERB2 is the verb or the adverbial clause, and is in the form of the infinitive as required by the implied conjunction used.
"a NOUN1" is the direct object of VERB2.
"for NOUN2" prepositional indirect object.
So if we re-add implicit words where possible we get the sentence "Google is to add pay in order to cover a tax for gays". There is still an implicit subject in the adverbial phrase, but we would need to chane the construction to add an explicit subject. The only thin left to chane is to switch to the more common "is going to add" rather than "is to add".
So we get: "Google is going to add pay in order to cover a tax for gays." Now that is readable.
Debian patches are usually kept to a miniumum, as long as upstream is still active. (Debian has become the de facto upstream for some packages, including a few GNU packages.)
The most common changes include adding a manpage if one does not exist, and tweaking the install paths so the system conforms to the FHS. Now sometimes larger changes do occur, but usually that is because upstream has not yet accepted the patch, or is sometimes a cherry picked back-ported patch from the development branch, but we try to keep these to a minimum.
Let us look at Debian's apache2 patches for an example.
The first patch adjusts "httpd --version" to display LSB_release information (i.e. identify the build as a Debian patched build).
The next patch changes an example script's she-bang line to use "/usr/bin/perl" instead of "/usr/local/bin/perl".
The next patch tweaks configuration include globbing so as not to include extra files that dpkg may create in/etc/apache2 while asking the user if they want to use the the shipped configuration file (if it has changed since the version installed, or use the customized file the user has created, or merge the changes.) This is clearly specific to dpkg-based distros.
The next patch tweaks the apxs script to not bother checking if Apache was compiled with shared library support, because Debian always configures it with shared library support, and Debian allows apxs to be used even when the "httpd" binary is not installed.
The next patch tweaks the config.layout file (which is explicitly designed to be customized by distributions!) to conform to the FHS. It also adjusts the configure script so the correct directories are used, and finally adds a #define to ap_config_layout.h.in that specifies the location of the default PID log.
The next patch further adjusts the apxs script to use httpd.conf rather than apache2.conf, tweaks the permissions it uses, and a few other path related adjustments.
It patches unixd.c to work correctly is suexec is built as a a shared library module.
The next patch changes the dbmmanage script to support both hash and btree based DBM files.
The next patch tweaks how the apxs script calls libtool to keep it from issuing an inappropriate warning.
The next patch tweaks envvars-std.in so that LD_LIBRARY_PATH is not propagated, since Debian has no need to for that, and copying in the building user's personal LD_LIBRARY_PATH is undesirable.
The next patch fixes prevents a buffer overflow attack on the htdigest executable.
The next patch changes suexec.c to use the close-on-exec flag for file descriptors, allowing the resulting error to be logged, which the existing code does not properly support (despite the claimsin the comments). This patch has also been comitted upstream.
The next patch tweaks the usage message to exose the -X flag.
The next patch tweaks logresolve to support line lengths greater than 1024 bytes. Many distos have this patch, but I am unsure if upstream has fixed it. I don't see any bug for it in Apache's bugzilla database.
The next patch is one for the configure script to permit the option "--enable-modules=none" to build an httpd with no optional modules enabled.
The next patch fixes a known security vulnerability (CVE-2007-1742) in suexec.c
The next patch fixes a segfault caused by inaproprtiately freeing memory in ab.c. This patch has been accepted upstream.
The next patch disbabled mod_deflate for HEAD requests to mitigate a ptential DOS attack.
There are more, but I am getting tired of typing them up.
Nothing will remove the need to know what you are doing, but having safe defaults, such as defaulting to printing strings escaped, requiring explicit action to print the raw input, helps a lot.
The idea is any decent developer will stop and ensure that the data printed out raw is in fact safe. It might be that it was a template file read in from the source directory, which is probably safe, especially if the server process has only read only access to that directory. Or perhaps the data has been sanitized so it need not be escaped.
Rails 3 does not sanitize data. The data is in the original form (barring datatype conversions like non-string fields in a database). Basic sanitation can be done by input validation, but generally that is used only for checking for validity of the input data.
But everything from an untrusted source (basically anything other than the raw html in the templates or html generated in the framework itself) is escaped by default. If you don't want full escaping, perhaps because you want to permit a subset of html, you can write a custom sanitation routine, and mark the result as safe.
Performance degradation of rails is not due to excessive abstraction. It is due to ruby being new enough that it is not yet highly optimized. The levels of abstraction have been carefully thought out, and levels providing no benefit have been excised. Java "enterprise" web applications usually have more levels of abstraction, quite often including multiple levels providing absolutely zero benefit, but are there because design patterns were blindly applied without any thought.
The fact that although PHP was originally intended to be used for web apps without a framework, and that if you don't use one now you are virtually guaranteed to have an obscene number of security holes, says a lot about PHP. Yes it is getting better, but there are better tools out there for many purposes. Hell, write your web app in Perl, like the one we are using now!
When they tax the corporations the corporations raise prices, but the higher prices also means a reduced demand, so they make less total profit. Look-up the term "deadweight loss". On a corporation's supply and demand chart the deadweight loss due to a tax represents the profit the corporation has lost as a result.
I have no idea Who retained the copyrights, by if it was the developer, then Rock Star North would be the current identity of the developer, so Take-Two Interactive would be the people to ask, not Sony.
Congrats. By using mysql_escape_string, rather than the correct function mysql_real_escape_string, you have just opened your hypothetical site up to SQL injection.
PHP should have fixed mysql_escape_string in place, and those few people whose sites would break as a result told too bad, you should not have relied on broken behavior.
The changes anybody relying on the broken behavior would need to make would be trivial, and it would prevent countless new PHP developers from using a dangerously broken function that was kept solely for backwards compatibility with already broken apps.
As for why you would want to use a different framework, well in Rails 3 you cannot accidentally open youself to SQL injection, since the idioms for using SQL prevent it. If you really need the unsafe behavior you need to do extra work (not much extra work, but still more than doing things safely).
Similarly you don't become XSS vulnerable by forgetting to escape output. Instead everything output that derives from a source other than framework code (so data from the user, data from the database, etc) is escaped by default. If you have data you know is safe, and need not be escaped, you can explicitly request that the string not be escaped.
No. Jack Bauer gets immunity for those who are willing to testify, (or at least give him information) in exchange for the immunity. What is rare is granting immunity to those who don't want to testify even if given immunity, and then dragging them in front of the court, and telling them that since they have immunity they are not allowed to refuse to testify.
See the difference. Only in the latter case would immunity be used to "force" testimony from an uncooperative witness. In the former case, it is used to freely obtain testimony from an otherwise uncooperative witness.
The GPUs are definately worse than CPUs in branching.
If your code splits into 8 different code paths at one point due to branching, your performance can be as bad as 1/8 the maximum, since rather than do anything remotely like actual branching, some GPUs just interleave the code of the different branches, with each instruction tagged as to whether which branch the code belongs to. So if the unit is processing an instrcution for a branch it is not on, it usts sits there doing nothing for one instruction cycle. This type of design may also have a depth limit on branching, so eight simultaneous code branches may not even be possible.
So the CPU performance only significantly degrades if a branch is mispredicted, while many GPU designs have performance suffer for every branch, even if it could have been accurately predicted.
It can be, but AIUI only for as long as the court case drags on. After the case end, the prosecutor cannot demand that you testify, so you cannot be held in contempt once again for failing to testify. So you may be held in contempt several times, but not unlimited, unless the court case goes on for ever.
Since no court is going to allow the trial to go on without end, or be postponed too many times, there is a limit, which may well be significantly less than the crime you could end up charged with after you testify ant the police use your testimony to find evidence. (It is impossible for them not to use it if they continue to search for evidence so even if the cops attempt to play by the rules, they will still be unable to do so.)
Granting immunity is used in a fair number of crimes, but using it as away to force tesitmony frm an uncooperative witness is very rare, Much more common is the witness is perfectly willing to testify in exchange for the immunity. Cases like organized crime are the very reason for the WITSEC program (more popularly known as the witness protection program).
An even bigger problem with attempting to use immunity to compel testimony is that Supreme Court has held that only use immunity is required to compel tesitimony. That means the indivudual can later be prosecuted for the crime, but his testimony of evidence dirived from his testimony cannot be used against him. The only problem is that that should mean that only evidence collected before the testimony should be admissible, because it is impossible to show that evidence later collected was not found based on the testimony, and the courts do not require the police to prove that, so only evidence that was obviously based on the testimony is ever excluded.
Furthermore. If they refuse to testify they are charged with only contempt of court, but if they do testify, and that helps the cops get evidence against him, he is in bad shape. So given the choice he may well accept the contempt charge.
Finally, it can be hard to trust the testimony of somebody forced to testify against their will. Hiding this fact from the jury would be a bad idea because the jury has a right to know any reason why a particular witness may be unreliable. On the other hand, if the jury does know, The testimony really does not help the prosecution much.
Testing it on 4 versions of Ubuntu, and on Debian, are pretty darn easy, since they are all very similar. Testing on Fedora was the only environment significantly dfferent from you you are likely using on a daily basis. Now also test on suse and gentoo. Debian, fedora, suse, and gentoo are currently the 4 main base linux platforms, and each do some things slightly differently, including a few differences that can make binary distribution a real pain. Also you did remember to test both the 32 and 64 bit versions of each, right?
A month is sill substantial, but it is not as completely outrageous as you seem to think.
The rules are only the USPS can deliver letters, unless one of several special exceptions apply.
Exception: The was delivered with no compensation including either goodwill or bartering.
Exception: the letter is in a properly addressed envelope, with the correct amount of postage on it, the envelope is sealed such that the it is obvious if opened, the stamp is canceled (in ink) by the sender, and either the sender or the courier mark the date of sending on the envelope in ink (i.e. postmark the envelope).
Exception: the letter is sent by or addressed to the courier.
Exception: is if the letter weighs more than 12.5 ounces, in which case it is basically a package.
Exception: If the service charges at least 6 times the basic postage rate.
Exception: a special agreement is in place between the USPS and the currier in question.
Exception: the letter relates directly to something else the courier is delivering.
Exception: the letter is deliver by a special messenger hired for this specific ocassion only, and is delivering a maximum of 25 letters.
Exception: the letters are being delivered before or after mailing. (Such as delivery to the post office)
Excpetion: The letter is extremely urgent, meaning it has certain specific time limits on the delivery, and that failure to meet these limits would cause the letter to become significantly less valuble or worthless. If the cost to deliver the letter is at least the greater of $3 or double the cost the postal service would have charged, that is considered to create a conclusive presumption that the letter is extremely urgent. Regardless of price, The envelope must be marked extremely urgent, or reference the relevant clause of the Code of Federal regulations, or otherwise be marked in some equivalent fashion.
Whoa! the rule is simple. If it is an emergency, and the service in question is acting in a way that would help the person being tracked they can get immediate access to the data. This is the case be it somebody reporting their house is on fire, or that they need an ambulance, or that they are under attack.
However, even in an emergency it would require a warrant to track somebody who is not direct helped by the tracking, such as tracking a suspect under investigation.
If there is doubt, you err on the side of caution, and get a warrant. for example if tracking somebody you think might have been kidnapped, that would normally fall under the first category, so if there is strong evidence of a kidnapping, such as a ransom note, you use it immediately, otherwise you get a warrant. If a person is simply missing, it is not nessisarally a reasonable assumption that they want to be found. You should need some strong evidence to support that idea. So you cannot assume it is in their interest to track them, so you would need a warrant. A ransom note means you can be reasonably confident the missing person would want to be located. So you don't need to get a warrant first. If it turns out the person faked their own kidnapping, then by making it appear that they would want to be located urgently, they implicitly permit the police to violate their privacy to find them.
Here is a list of TLDs that work as web addresses: (be sure to enter them with http:/// and a dot at the end or your browser might not make it to the site, firefox for example will assume it is invalid and try adding a 'www.' and a '.com' unless i have already been to the page by explicitly adding a dot.)
A null TLD is absurd. If you had a null tld than the fully qualified name of the website would be "slashdot.." (with two dots at the end). Since by convention we do not require the last dot, the domain you would type into your browser is "slashdot." with that last dot absolutely mandatory. Unfortunately that would conflict with the fully qualified name of a hypothetical slashdot TLD, so it is a non-starter.
What you want is a for people to just use top level domains to host their sites. That is quite possible. A top Level domain is a domain like any other, and can have an 'A' record associated with it. Indeed the website http://ac/ works just fine, being website for the Network Information center (NIC) for Ascension Island. (the site is also available at the more usual domain of http://nic.ac/ )
So this is a volumetric style display. It can only display objects within its volume. However full volumetric displays this display has only natural horizontal parallax. It can fake vertical parallax using head tracking. It does have one conceptual advantage over proper volumetric displays, namely that it does not require that you can always see through to the back of he shape, but it should be able to emulate that if desired.
- - - -
Let me attempt to create a classification system for 3D display technology.
Volumetric refers to any technology that is restricted to displaying an image within some fixed size area. It cannot show things like stereoscopic movies. Volumetric displays have natural parallax in both directions, so can be observed correctly by any number of viewers. They can be viewed from any direction, except that equipment may obscure the views from some direction.
A pseudo-volumetric display is one that can only display in a fixed volume, but fails to meet the one of the requirements of a volumetric display, such as having only natural parallax in one direction, not being viewable from all directions, or only being able to display points on the exterior of the volume.
Examples:
The display of this article, since it lacks natural vertical paralax.
Certain types of holograms meat this definition. they have natural parallax in both directions, but can only be viewed from a limited number of angles.
The following device based on a a structure of rotating LEDs. http://www.youtube.com/watch?v=oLygWkHo9nw This is pesudo-volumetric only because this particular device can only show things on a sphere, and a ring around the sphere. It also does not let you see the far side of the shape. It is entirely possible to build a full volumetric device using the same technology.
Now we have the remaining technology. These pretty much always use one or more flat screens, but that is not a requirement.
A very familiar technology is 2D projection. This is the projection of a 3D image on a 2D surface. This is what we used to mean when we talked about 3D video games, for example. I don't think any examples are needed here.
Now before I go on to talk about additional display types, I should define some terms.
Autosteroscopic indicates that a display gives a stereoscopic image without the need for glasses, goggles, etc. There seems to be no standardized term for the opposite, whIch i will call variosteroscopic
Semi-Immersive means that the view changes depending on the observers position. I mean this beyond parallax. Think of a display acting like a window, so if you stand to the far left or far right you can see different things, while only parallax would give stereoscopy, but you would see the same image from both sides of the display.
Fully-immersive has not just a single window, but surrounds you, or seems to, anyway. VR goggles that track head movement and rotation can supply this kind of display. Volumetric displays that can be walked through also qualify. Later I will discuss how the holodeck fits in.
Now we can get on to our display types.
Variosteroscopic, non-immersivedisplays. These should be very familiar. They are what mov
The signer is who you think he is. The signed root zone lets you know that the root zone has not been tampered with. If you don't trust the IANA, you might as well stop using the internet entirely, since the IANA decides what the root servers serve up. The root zone contains the public keys for the "org." domain. Only Afilias, who maintains the "org." domain can request the key for.org in the root zone to be changed. Thus if the root zone signature is good, we know that the key in it for "org." belongs to the maintainer of "org." so you should trust it (as if the maintainer of "org." was maliacious you are screwed anyway. By the same set of concepts you know that they key for a second level domain belongs to the owner of the second level domain, and if you don't trust them, then you just should not be visiting their site.
so if all the signatures are valid, you know there is no hijacking, and the records returned are those specified by the owner of the domain.
Yes. Injecting a header can have all sorts of negative consequences.
My feelings on networks is that if I present a packet with a valid IP address corresponding to a computer accepting packets:
the packet should arrive there in a reasonable timeframe unless:
I have explicitly requested some kind of filtering which matches this packet
The administrator of the other computer has requested some kind of filtering matching this packet
or there is no route between my computer and the target computer (implying an internet-wide netsplit)
The packet will arrive unaltered, except that any values in the packet header intended to be altered in transit (such as the TTL value) may be altered in the manner described in the protocol documentation.
However that just never happens. Undesired filtering, is frequently present, both of traceroute packets, and often of specific inbound and outbound ports.
Even when an ISP gets that right, routing packets often gets messed up. Sometimes an ISP will insist upon routing packets to some machine via a route that is down, even though there are other routes it could take. This is a consequence of the way routing works in practice, with ISPs frequently deciding to override the routes that would otherwise be used, without properly defining backup routes in the event that some connection goes down. Even worse is when the system insists upon using a route with a flaky or overloaded hop, such that only a fraction of the packets make it through. I've seen that before, and it is very annoying.
Yes, but read up on the Nyquist-Shannon sampling theorem which states that a signal with a maximum frequency component of F Hz, can be completely dtermined by sample at any rate which exceeds 2F.
This therom is completely valid for only for periodic signals with infinite samples, but for real world signals at finite number of samples it is an extremely close approximation. To be safe it is common to add about 10% to the doubled frequency. At that point the errors of the sound system in recreating the sound should outweigh the error from the approximation except in contrived signals.
Obviously sampling a signal with a frequency component greater than half the sampling frequency can be problematic, especially if those frequencies were high amplitude, but again in practice this is generally not much of an issue, and a simple analog lowpass filter can alleviate the issue.
So in total while a 192kHz sampling rate will result in an output waveform closer to the original than a 44.1kHz sampling rate, it will not actually make much difference in practice.
Now using 24/44.1kHz rather than 16/44.1kHz I could understand since those extra bits for encoding each sample could make quite a bit of difference. Of course I'm comparing uncompressed wave files there. Lossy compression algorithms might just kill off that difference.
Sure, but what about If you ere using a disposable dessicant? If the evaporative cooler cools the air by causing a phase change of water from liquid to gas, increasing entropy but decreasing temperature, wouldn't the phase change of water the desiccant causes which is from a high entropy state (gas) to a lower entropy state (liquid), require increasing the temperature to compensate, so the net entropy change is no longer negative, which would violate the second law of thermodynamics?
That is what I am having trouble figuring out. But as I said, It has been a long time since i studied the physics of fluids, and even that study mostly ignored the physics of solutions, which is definitely relevant here.
Slashdot Mirror
Perhaps The best way to do this is to define some terms.
One term I will define is logical Many interfaces label this a block. This is the minimum amount of addressable data. It is what the kernel sees as the block size of the disk drive, and also used in the drive communication protocols. The file systems also often use them as a sector size, but that is completely independent of the size of a logical block in disk signaling, which is what most kernels view the device in terms of. From this point forward I will call them "logical blocks". Logical blocks are usually 4096 bytes in size.
Flash devices are generally bit readable and bit writable, but only erasable in large blocks, called "physical blocks". In practice the controller can only address them in increments larger than single bit, but smaller than the full physical block size.
The drive maps multiple logical blocks to a single physical block. This can be done in a haphazard fashion, but the simplest way is to map the physical blocks to the number of consecutive logical blocks that they can fit. So in the beginning the disk can be written to directly, since all the physical blocks are blank. If a logical block needs to be changed, just read the other logical blocks from the original physical block, and write the whole thing to an empty block. However, eventually, all physical blocks will have been written to. From this point forward, a physical block must be erased prior to being used.
The trim command tells the disk of any logical blocks no longer in use. If all of the logical blocks in a physical block are not in use, then the drive can erase that physical block when idle, and be ready to use it with no speed degradation. If it tracks which individual logical blocks are not in use, it can also avoid reading them in any future 'read-erase-write' cycle.
If the drive keeps a pool of unused physical blocks around, it can normally avoid the overhead of erasing on a new write, merely reading any logical blocks from the old physical block, and writing everything to a new physical block, and mark the old physical block for erasure while idle.
If a significant pool of empty physical blocks are maintained, then maximum write performance remains possible as long as the amount written at one time is less than the amount of empty physical blocks in the pool. Only when writing too much at once does the pool run out, and erasures occur during writing, causing poor performance.
Thus TRIM is only particularly valuable if the drive has an unreasonably small collection of spare physical blocks, or if the workload writing lots of data (sequential or not) at one time.
Low end drives suffer from the former problem, keeping few if any spare physical blocks around, while higher end drives can maintain optimum write performance at all times, except for large sustained writes.
Whoa! It can go either way an erased flash block is all ones or all zeros, depending on convention. Assuming the (less common) all zero convention, an erased black can have bits set one at a time, but any time a bit must be unset, the block must be erased. The fastest write performance occurs when the block is already erased.
The next fastest is when it can be erased, and then just the new data written. The slowest is to read, erase, and the write the whole flash block.
It is entirely permissible and even sensible to the drive to actually erase any block filled with only TRIM'd sectors, although if the flash block has a mix of TRIM'd and non-TRIM'd sectors, it can skip reading the untrimed ones when rewriting.
>if you know C++ you can get a job in a heartbeat.
Yea people with real skills are never unemployed.
Even if you can't code, if you understand computers at the electrical, wire, clock, and register level, and understand binary and hex, you'll never be unemployed.
That first part sounds like somebody familiar with RTL level design, using Verilog or VHDL. That is a very specialized level of knowledge. That said there are definitely people with that level of knowledge who are unemployed. If you know computers at that level you inherently know hex and binary. If you did not know binary you would never be able to do any design work, for example.
Now if you mean, will never be unemployed for the long term, a few months at most, I would probably agree with that.
Colleges can help you but are ultimately unnecessary. Everything you need to know is available for free, or nearly so.
True. Colleges do hep though in making sure you have sufficient awareness of the types of information out there, and by what name it is known. I did not learn anything about computers in college that I could not have learned for free, but I did learn several things that I would probably not have learned otherwise, simply because they were not far enough inside my area of interest. Yet, I most definitely have found this new knowledge useful on occasion.
An engineer with any talent is always building something, because they don't have an option. They have to do it or they go crazy. Whether or not there's a monetary reward is secondary to the need to create. You don't need a job to create something an employer would be interested in seeing.
More accurate would be that the engineering is always solving problems, not necessarily building anything. Even what they do build may not be worth showing off to an employer.
Stupid design? I don't know. My logitech keyboard has 2 rows of two in series (phsyical and logical, athough not touching, but seperated by a small amount so microsoft's invention would work here).
The idea is to get a nominal 3V, which is is closer to 2.4 volts under load. However it draws wnough current that two AA cells in series do not last long enough, so they added a second set of two AA cells in parallel to the first set. The result is that the device works fine with only two cells, but with 4 it lasts a much more reasonable time. (This ability to run on only 2 batteries was not a documented feature)
One of Apple's mice also used this type of design, however here it was a documented feature.
I'm reasonably confident that diodes were used in both designs to prevent shorting if batteries were placed backwards.
Fucking magnets, how do they work?
Quite well, thank you for asking.
The sytntax is:
NOUN [is] VERB1 NOUN1 ([in order] VERB2 a NOUN2 (for NOUN3))
The verb "is" is implied. this is the Zero copula, although its use in this manner is considered questionable as legal grammar but is common in headlines.
VERB1 is an infinitive, used with the implied "is" to create a future tense (like in he sentence "john is to leave tonight". In some regions, my own included, the alternative construction "is going" + infinitive sounds more natural, but is equivalent.)
NOUN1 is the direct object of VERB1.
([in order] VERB2 a NOUN2 (for NOUN3)) an adverbial clause, of the purpose type, modifying VERB1, and using an implied conjunction of "in order to" (but that two is part of the following verb. It uses an implied subject of "Google".
VERB2 is the verb or the adverbial clause, and is in the form of the infinitive as required by the implied conjunction used.
"a NOUN1" is the direct object of VERB2.
"for NOUN2" prepositional indirect object.
So if we re-add implicit words where possible we get the sentence "Google is to add pay in order to cover a tax for gays". There is still an implicit subject in the adverbial phrase, but we would need to chane the construction to add an explicit subject. The only thin left to chane is to switch to the more common "is going to add" rather than "is to add".
So we get: "Google is going to add pay in order to cover a tax for gays." Now that is readable.
Debian patches are usually kept to a miniumum, as long as upstream is still active. (Debian has become the de facto upstream for some packages, including a few GNU packages.)
The most common changes include adding a manpage if one does not exist, and tweaking the install paths so the system conforms to the FHS. Now sometimes larger changes do occur, but usually that is because upstream has not yet accepted the patch, or is sometimes a cherry picked back-ported patch from the development branch, but we try to keep these to a minimum.
Let us look at Debian's apache2 patches for an example.
The first patch adjusts "httpd --version" to display LSB_release information (i.e. identify the build as a Debian patched build).
The next patch changes an example script's she-bang line to use "/usr/bin/perl" instead of "/usr/local/bin/perl".
The next patch tweaks configuration include globbing so as not to include extra files that dpkg may create in /etc/apache2 while asking the user if they want to use the the shipped configuration file (if it has changed since the version installed, or use the customized file the user has created, or merge the changes.) This is clearly specific to dpkg-based distros.
The next patch tweaks the apxs script to not bother checking if Apache was compiled with shared library support, because Debian always configures it with shared library support, and Debian allows apxs to be used even when the "httpd" binary is not installed.
The next patch tweaks the config.layout file (which is explicitly designed to be customized by distributions!) to conform to the FHS. It also adjusts the configure script so the correct directories are used, and finally adds a #define to ap_config_layout.h.in that specifies the location of the default PID log.
The next patch further adjusts the apxs script to use httpd.conf rather than apache2.conf, tweaks the permissions it uses, and a few other path related adjustments.
It patches unixd.c to work correctly is suexec is built as a a shared library module.
The next patch changes the dbmmanage script to support both hash and btree based DBM files.
The next patch tweaks how the apxs script calls libtool to keep it from issuing an inappropriate warning.
The next patch tweaks envvars-std.in so that LD_LIBRARY_PATH is not propagated, since Debian has no need to for that, and copying in the building user's personal LD_LIBRARY_PATH is undesirable.
The next patch fixes prevents a buffer overflow attack on the htdigest executable.
The next patch changes suexec.c to use the close-on-exec flag for file descriptors, allowing the resulting error to be logged, which the existing code does not properly support (despite the claimsin the comments). This patch has also been comitted upstream.
The next patch tweaks the usage message to exose the -X flag.
The next patch tweaks logresolve to support line lengths greater than 1024 bytes. Many distos have this patch, but I am unsure if upstream has fixed it. I don't see any bug for it in Apache's bugzilla database.
The next patch is one for the configure script to permit the option "--enable-modules=none" to build an httpd with no optional modules enabled.
The next patch fixes a known security vulnerability (CVE-2007-1742) in suexec.c
The next patch fixes a segfault caused by inaproprtiately freeing memory in ab.c. This patch has been accepted upstream.
The next patch disbabled mod_deflate for HEAD requests to mitigate a ptential DOS attack.
There are more, but I am getting tired of typing them up.
Nothing will remove the need to know what you are doing, but having safe defaults, such as defaulting to printing strings escaped, requiring explicit action to print the raw input, helps a lot.
The idea is any decent developer will stop and ensure that the data printed out raw is in fact safe. It might be that it was a template file read in from the source directory, which is probably safe, especially if the server process has only read only access to that directory. Or perhaps the data has been sanitized so it need not be escaped.
Rails 3 does not sanitize data. The data is in the original form (barring datatype conversions like non-string fields in a database). Basic sanitation can be done by input validation, but generally that is used only for checking for validity of the input data.
But everything from an untrusted source (basically anything other than the raw html in the templates or html generated in the framework itself) is escaped by default. If you don't want full escaping, perhaps because you want to permit a subset of html, you can write a custom sanitation routine, and mark the result as safe.
Performance degradation of rails is not due to excessive abstraction. It is due to ruby being new enough that it is not yet highly optimized. The levels of abstraction have been carefully thought out, and levels providing no benefit have been excised. Java "enterprise" web applications usually have more levels of abstraction, quite often including multiple levels providing absolutely zero benefit, but are there because design patterns were blindly applied without any thought.
The fact that although PHP was originally intended to be used for web apps without a framework, and that if you don't use one now you are virtually guaranteed to have an obscene number of security holes, says a lot about PHP. Yes it is getting better, but there are better tools out there for many purposes. Hell, write your web app in Perl, like the one we are using now!
Econ 101 covers this.
When they tax the corporations the corporations raise prices, but the higher prices also means a reduced demand, so they make less total profit. Look-up the term "deadweight loss". On a corporation's supply and demand chart the deadweight loss due to a tax represents the profit the corporation has lost as a result.
I have no idea Who retained the copyrights, by if it was the developer, then Rock Star North would be the current identity of the developer, so Take-Two Interactive would be the people to ask, not Sony.
Congrats. By using mysql_escape_string, rather than the correct function mysql_real_escape_string, you have just opened your hypothetical site up to SQL injection.
PHP should have fixed mysql_escape_string in place, and those few people whose sites would break as a result told too bad, you should not have relied on broken behavior.
The changes anybody relying on the broken behavior would need to make would be trivial, and it would prevent countless new PHP developers from using a dangerously broken function that was kept solely for backwards compatibility with already broken apps.
As for why you would want to use a different framework, well in Rails 3 you cannot accidentally open youself to SQL injection, since the idioms for using SQL prevent it. If you really need the unsafe behavior you need to do extra work (not much extra work, but still more than doing things safely).
Similarly you don't become XSS vulnerable by forgetting to escape output. Instead everything output that derives from a source other than framework code (so data from the user, data from the database, etc) is escaped by default. If you have data you know is safe, and need not be escaped, you can explicitly request that the string not be escaped.
No. Jack Bauer gets immunity for those who are willing to testify, (or at least give him information) in exchange for the immunity. What is rare is granting immunity to those who don't want to testify even if given immunity, and then dragging them in front of the court, and telling them that since they have immunity they are not allowed to refuse to testify.
See the difference. Only in the latter case would immunity be used to "force" testimony from an uncooperative witness. In the former case, it is used to freely obtain testimony from an otherwise uncooperative witness.
The GPUs are definately worse than CPUs in branching.
If your code splits into 8 different code paths at one point due to branching, your performance can be as bad as 1/8 the maximum, since rather than do anything remotely like actual branching, some GPUs just interleave the code of the different branches, with each instruction tagged as to whether which branch the code belongs to. So if the unit is processing an instrcution for a branch it is not on, it usts sits there doing nothing for one instruction cycle. This type of design may also have a depth limit on branching, so eight simultaneous code branches may not even be possible.
So the CPU performance only significantly degrades if a branch is mispredicted, while many GPU designs have performance suffer for every branch, even if it could have been accurately predicted.
It can be, but AIUI only for as long as the court case drags on. After the case end, the prosecutor cannot demand that you testify, so you cannot be held in contempt once again for failing to testify. So you may be held in contempt several times, but not unlimited, unless the court case goes on for ever.
Since no court is going to allow the trial to go on without end, or be postponed too many times, there is a limit, which may well be significantly less than the crime you could end up charged with after you testify ant the police use your testimony to find evidence. (It is impossible for them not to use it if they continue to search for evidence so even if the cops attempt to play by the rules, they will still be unable to do so.)
Granting immunity is used in a fair number of crimes, but using it as away to force tesitmony frm an uncooperative witness is very rare, Much more common is the witness is perfectly willing to testify in exchange for the immunity. Cases like organized crime are the very reason for the WITSEC program (more popularly known as the witness protection program).
An even bigger problem with attempting to use immunity to compel testimony is that Supreme Court has held that only use immunity is required to compel tesitimony. That means the indivudual can later be prosecuted for the crime, but his testimony of evidence dirived from his testimony cannot be used against him. The only problem is that that should mean that only evidence collected before the testimony should be admissible, because it is impossible to show that evidence later collected was not found based on the testimony, and the courts do not require the police to prove that, so only evidence that was obviously based on the testimony is ever excluded.
Furthermore. If they refuse to testify they are charged with only contempt of court, but if they do testify, and that helps the cops get evidence against him, he is in bad shape. So given the choice he may well accept the contempt charge.
Finally, it can be hard to trust the testimony of somebody forced to testify against their will. Hiding this fact from the jury would be a bad idea because the jury has a right to know any reason why a particular witness may be unreliable. On the other hand, if the jury does know, The testimony really does not help the prosecution much.
Testing it on 4 versions of Ubuntu, and on Debian, are pretty darn easy, since they are all very similar. Testing on Fedora was the only environment significantly dfferent from you you are likely using on a daily basis. Now also test on suse and gentoo. Debian, fedora, suse, and gentoo are currently the 4 main base linux platforms, and each do some things slightly differently, including a few differences that can make binary distribution a real pain. Also you did remember to test both the 32 and 64 bit versions of each, right?
A month is sill substantial, but it is not as completely outrageous as you seem to think.
The rules are only the USPS can deliver letters, unless one of several special exceptions apply.
Exception: The was delivered with no compensation including either goodwill or bartering.
Exception: the letter is in a properly addressed envelope, with the correct amount of postage on it, the envelope is sealed such that the it is obvious if opened, the stamp is canceled (in ink) by the sender, and either the sender or the courier mark the date of sending on the envelope in ink (i.e. postmark the envelope).
Exception: the letter is sent by or addressed to the courier.
Exception: is if the letter weighs more than 12.5 ounces, in which case it is basically a package.
Exception: If the service charges at least 6 times the basic postage rate.
Exception: a special agreement is in place between the USPS and the currier in question.
Exception: the letter relates directly to something else the courier is delivering.
Exception: the letter is deliver by a special messenger hired for this specific ocassion only, and is delivering a maximum of 25 letters.
Exception: the letters are being delivered before or after mailing. (Such as delivery to the post office)
Excpetion: The letter is extremely urgent, meaning it has certain specific time limits on the delivery, and that failure to meet these limits would cause the letter to become significantly less valuble or worthless. If the cost to deliver the letter is at least the greater of $3 or double the cost the postal service would have charged, that is considered to create a conclusive presumption that the letter is extremely urgent. Regardless of price, The envelope must be marked extremely urgent, or reference the relevant clause of the Code of Federal regulations, or otherwise be marked in some equivalent fashion.
Whoa! the rule is simple. If it is an emergency, and the service in question is acting in a way that would help the person being tracked they can get immediate access to the data. This is the case be it somebody reporting their house is on fire, or that they need an ambulance, or that they are under attack.
However, even in an emergency it would require a warrant to track somebody who is not direct helped by the tracking, such as tracking a suspect under investigation.
If there is doubt, you err on the side of caution, and get a warrant. for example if tracking somebody you think might have been kidnapped, that would normally fall under the first category, so if there is strong evidence of a kidnapping, such as a ransom note, you use it immediately, otherwise you get a warrant. If a person is simply missing, it is not nessisarally a reasonable assumption that they want to be found. You should need some strong evidence to support that idea. So you cannot assume it is in their interest to track them, so you would need a warrant. A ransom note means you can be reasonably confident the missing person would want to be located. So you don't need to get a warrant first. If it turns out the person faked their own kidnapping, then by making it appear that they would want to be located urgently, they implicitly permit the police to violate their privacy to find them.
Here is a list of TLDs that work as web addresses: (be sure to enter them with http:/// and a dot at the end or your browser might not make it to the site, firefox for example will assume it is invalid and try adding a 'www.' and a '.com' unless i have already been to the page by explicitly adding a dot.)
http://ac./
http://ai./
http://bi./
http://cm./ (there is no http server running at the IP this resolves to)
http://dk./
http://gg./
http://hk./ (there is no http server running at the IP this resolves to)
http://io./
http://je./
http://ph./ (Here I get an ASP error, which looks to be part of an asp dispatched virtual hosting solution.)
http://pn./
http://pw./ (there is no http server running at the IP this resolves to)
http://sh./ (there is no http server running at the IP this resolves to)
http://tk./
http://to./ The shortest URL shortener in existence, having only 3 characters in the domain itself (and some browsers will work with only 2 of them)
http://uz./
http://wz./ (there is no http server running at the IP this resolves to)
So using top level domains as regular domains is very possible.
A null TLD is absurd. If you had a null tld than the fully qualified name of the website would be "slashdot.." (with two dots at the end). Since by convention we do not require the last dot, the domain you would type into your browser is "slashdot." with that last dot absolutely mandatory. Unfortunately that would conflict with the fully qualified name of a hypothetical slashdot TLD, so it is a non-starter. What you want is a for people to just use top level domains to host their sites. That is quite possible. A top Level domain is a domain like any other, and can have an 'A' record associated with it. Indeed the website http://ac/ works just fine, being website for the Network Information center (NIC) for Ascension Island. (the site is also available at the more usual domain of http://nic.ac/ )
So this is a volumetric style display. It can only display objects within its volume. However full volumetric displays this display has only natural horizontal parallax. It can fake vertical parallax using head tracking. It does have one conceptual advantage over proper volumetric displays, namely that it does not require that you can always see through to the back of he shape, but it should be able to emulate that if desired.
- - - -
Let me attempt to create a classification system for 3D display technology.
Volumetric refers to any technology that is restricted to displaying an image within some fixed size area. It cannot show things like stereoscopic movies. Volumetric displays have natural parallax in both directions, so can be observed correctly by any number of viewers. They can be viewed from any direction, except that equipment may obscure the views from some direction.
Some examples:
A pseudo-volumetric display is one that can only display in a fixed volume, but fails to meet the one of the requirements of a volumetric display, such as having only natural parallax in one direction, not being viewable from all directions, or only being able to display points on the exterior of the volume.
Examples:
Now we have the remaining technology. These pretty much always use one or more flat screens, but that is not a requirement.
A very familiar technology is 2D projection . This is the projection of a 3D image on a 2D surface. This is what we used to mean when we talked about 3D video games, for example. I don't think any examples are needed here.
Now before I go on to talk about additional display types, I should define some terms.
Autosteroscopic indicates that a display gives a stereoscopic image without the need for glasses, goggles, etc. There seems to be no standardized term for the opposite, whIch i will call variosteroscopic
Semi-Immersive means that the view changes depending on the observers position. I mean this beyond parallax. Think of a display acting like a window, so if you stand to the far left or far right you can see different things, while only parallax would give stereoscopy, but you would see the same image from both sides of the display.
Fully-immersive has not just a single window, but surrounds you, or seems to, anyway. VR goggles that track head movement and rotation can supply this kind of display. Volumetric displays that can be walked through also qualify. Later I will discuss how the holodeck fits in.
Now we can get on to our display types.
Variosteroscopic, non-immersive displays. These should be very familiar. They are what mov
The signer is who you think he is. The signed root zone lets you know that the root zone has not been tampered with. If you don't trust the IANA, you might as well stop using the internet entirely, since the IANA decides what the root servers serve up. The root zone contains the public keys for the "org." domain. Only Afilias, who maintains the "org." domain can request the key for .org in the root zone to be changed. Thus if the root zone signature is good, we know that the key in it for "org." belongs to the maintainer of "org." so you should trust it (as if the maintainer of "org." was maliacious you are screwed anyway. By the same set of concepts you know that they key for a second level domain belongs to the owner of the second level domain, and if you don't trust them, then you just should not be visiting their site.
so if all the signatures are valid, you know there is no hijacking, and the records returned are those specified by the owner of the domain.
Yes. Injecting a header can have all sorts of negative consequences.
My feelings on networks is that if I present a packet with a valid IP address corresponding to a computer accepting packets:
However that just never happens. Undesired filtering, is frequently present, both of traceroute packets, and often of specific inbound and outbound ports.
Even when an ISP gets that right, routing packets often gets messed up. Sometimes an ISP will insist upon routing packets to some machine via a route that is down, even though there are other routes it could take. This is a consequence of the way routing works in practice, with ISPs frequently deciding to override the routes that would otherwise be used, without properly defining backup routes in the event that some connection goes down. Even worse is when the system insists upon using a route with a flaky or overloaded hop, such that only a fraction of the packets make it through. I've seen that before, and it is very annoying.
Yes, but read up on the Nyquist-Shannon sampling theorem which states that a signal with a maximum frequency component of F Hz, can be completely dtermined by sample at any rate which exceeds 2F.
This therom is completely valid for only for periodic signals with infinite samples, but for real world signals at finite number of samples it is an extremely close approximation. To be safe it is common to add about 10% to the doubled frequency. At that point the errors of the sound system in recreating the sound should outweigh the error from the approximation except in contrived signals.
Obviously sampling a signal with a frequency component greater than half the sampling frequency can be problematic, especially if those frequencies were high amplitude, but again in practice this is generally not much of an issue, and a simple analog lowpass filter can alleviate the issue.
So in total while a 192kHz sampling rate will result in an output waveform closer to the original than a 44.1kHz sampling rate, it will not actually make much difference in practice.
Now using 24/44.1kHz rather than 16/44.1kHz I could understand since those extra bits for encoding each sample could make quite a bit of difference. Of course I'm comparing uncompressed wave files there. Lossy compression algorithms might just kill off that difference.
Sure, but what about If you ere using a disposable dessicant? If the evaporative cooler cools the air by causing a phase change of water from liquid to gas, increasing entropy but decreasing temperature, wouldn't the phase change of water the desiccant causes which is from a high entropy state (gas) to a lower entropy state (liquid), require increasing the temperature to compensate, so the net entropy change is no longer negative, which would violate the second law of thermodynamics?
That is what I am having trouble figuring out. But as I said, It has been a long time since i studied the physics of fluids, and even that study mostly ignored the physics of solutions, which is definitely relevant here.