I firmly belive that I am among the very few people who have played the entire half-life series, and yet have spent less than 10 minutes playing any source or goldsource multiplayer game.
I play RTS games solely for the single player campaigns. I would get bored with the skirmish mode very quickly, and have zero interest in the multiplayer mode.
Playing local multiplayer with friends is indeed fun, but I don't have any friends over (pretty much ever), so I generally find that pretty worthless.
Andy why do you need admin privileges? To install a kernel-mode driver! Even the admin users cannot directly trap CTRL-ALT-DELETE and the right to install new services/Drivers can be restricted even for administrator accounts (but in practice never is).
Hell yes! I want move #43 from that disc, but they send me the whole thing, complete with 49 bundled crap movies, exactly like how albums often have only one or two decent songs and the rest is junk.
Thanks to the monstrous copy protection system likely in use by then, a single unreadability bit anywhere on the disk, will prevent playing every title. Furthermore, The system will be so terribly sensitive to minor scratches that merely putting the disk in the player will have a 50% chance of rending the disc valueless.
It would just be so much easier to stream 50 3D surround-picture films via the successor to bit-torrent over my stolen satellite down-link, thank-you-very-much!
Chrome currently has "phantom tabs". They are pinned tabs that have been closed. They show up in the tab bar just like all other pinned tabs, but they are slightly translucent, to distinguish them from other pinned tabs. They have no attached rendering engine, so the only resources they consume are those needed to display the favicon. But click on it, and a rendering engine is spawned, and the tab acts just like any other.
Thus when made phantom they would qualify as super-lightweight. Granted that currently it is only experimental, and the tabs do not reopen in phantom state but regular pinned-tab state, but that is coming.
Similarly, this tab-candy extension is looking at releasing the resources of tabs that have not been used recently n a similar fashion.
Primer's timeline though is extremely complicated, and does rely on a discrete metatime interpretation of time travel. Furthermore, the only person who apparently has a verified (by the film's author) correct timeline for the film has an explanation that is unreadable, because it was written defensively to ward off specific arguments against specific points, which new readers are completely unfamiliar with.
A simple circular polarization filter over the top of an LCD results in light that can be viewed in any angle through regular (linear) polarized glasses. This is not commonly found because the extra layer hurts contrast somewhat and also costs more, but You do see it in some places.
Really all versions? Going all the way back to 1.0, and also including the CE versions? I strongly doubt that! Perhaps it dates all the way back to NT4, but that is still very, very different than affecting all Windows versions.
I believe there may be more than one type of e-Fuse.
Most processors have special fuses, which can be set only once, at the factory, usually via jtag, that are set to disable any components of the processor that are not working, embed the unique serial number, etc. On setting a bit, the chip is physically changed, so it cannot be reset. We used to call this PROM technology, but I have seen the label eFuse used for it before.
The UltraSparc chips for example have an array of poly fuses that can be blown by an electrical pulse, which is used to store data configuring the system to avoid any defective subcores, etc, as well as specifying the serial number Sun called this part of the chip the eFuse.
Then there is the technology currently in question, which sounds to me more like configuration bits stored in EEPROM, like the "fuses" of a PIC microcontroller, which are specified in the bitfile downloaded to the processor, which can be reset via JTAG.
Honestly, yes. It allows for rapid development, the end code is all too often unmaintainable, and it is among the easier Turing-complete web technologies to learn. (Granted the programing languge itself is a superset of ECMAscript, so Javascript experience transfers partially, but browser DOM experience, and cross-browser coding experience does not really help.)
Unlike VB, the underlying language is actually reasonably good. It is an ECMAscript superset, as I already mentioned, so it is a prototype-based language. Like all decent dynamic languages ECMAscript (and thus both Javascript and Actionscript) permits procedural, object-oriented, and even functional programming paradigms. However, the extensions to ECMAscript include more traditional OO support than ECMAscript alone provides, making it possible to avoid many of the unusual idioms javascript OO design requires.
One interesting feature of Actionscript is the optional static typing. While the language is fundamentally dynamically typed, it provides the option of specifying static types on variables and function/method arguments. This primarily allows for better optimization, but also allows for better static analysis, including "compile-time" checking for certain kinds of type errors.
Thus a program can initially be designed using dynamicly typed variables for ease and speed of initial development, and later be slowly migrated to static typing during maintenance, providing the benefits of "compile-time" type-checking, as well as performance benefits. Even then, it is not necessary to commit to being fully statically typed, letting one leave dynamic those parts of the code that would benefit from that.
Thus the language itself is not one that an experienced developer would feel constrained in, nor would it be one they would feel embarrassed to use (which is very different to VB).
Java can be used for games, no doubt about it, but those type of games you are mentioning can have most of the code written before you even decide on the specifics of the game.
They are not as experimental as most flash games.
Flash lets you through together a game quickly to test a game-play mechanic, while the java game will probably be more technically solid, but would take more time to develop. Most of my favorite flash games would be many times harder to write in Java.
On the other hand, Java can definitely handle more than flash. Flash's 3D handling is rather primitive (but has been improving in the latest releases), and Flash does have slower code execution than Java, so code-heavy games (chess games, flight sims, etc) would also benefit from Java over Flash.
Java applets work, but the language is somewhat clunky[1], at least compared to flash, and for the longest time there were no good libraries for creating Java applet games. On the other hand, Flash was designed for animations and interactive animations, meaning it came by default with many of the necessary tools for building a game.
Indeed to this day, most flash games are developed from scratch, rather than using a pre-existing game library, even though several exist.
Java is also not as widely installed on home systems as Flash is.
Footnotes:
[1] In this context by clunky I mean that it does not permit many quick and dirty hacks that many scripting languages permit, tending to enforce at least some elements of proper OO design (although admittedly not all of them). In some contexts this is a good thing, as it discourages the quick and dirty hacks. However for game development, permitting the hacks can allow a developer to quickly try out an idea, and implement it properly only once it has been shown to be workable.
As long as the developer is disciplined enough to replace the hack with proper code, this can speed up testing out ideas without causing the code quality to suffer. If the hack is not replaced, this
Actually, "library" can and does mean "collection of" in English. Indeed that is the exact meaning of "library" in a "code library". Alone "library" implies a collection of books, but "music library" and similar terms are definitely in use.
"Library" when used alone may imply a lending library. Context is necessary to determine if lending library or book collection was intended. When used with modifiers, lending library is usually not implied, with a few exceptions, like "public library".
The only issue with your post is that because this is Slashdot, people may assume that "library" means code library in such a context, rather than "collection of". Thus it may be clearer to explicitly say collection.
Yes. The integral fast reactor design is very nice.
The key to the design is that it can burn just about anything, repeatedly through reprocessing, leaving only short half life and long half life waste.
Short half life waste is extremely dangerous, but can decay to safe levels in only 200-400 years, as opposed to the around 10,000 years the waste from traditional reactors is often quoted at. Long half-life waste, such as that found in the IFR waste is not a significant radiation concern. Much of stuff could safely be held in your hand, not unlike uranium ore. Granted like uranium ore, prolonged exposure should be avoided, but brief exposures to significant sized chunks of long-halflife waste is not particularly worrying.
It is the medium half-life wastes in the output of most reactors that are really concerning. The half life is long enough that the material takes a really long time to decay to safe levels, while the half-life is also short enough that the waste is highly dangerous.
On annother note, the IFR is breeder reactor, but it is one of very few breeder-based designs that pose absolutely no real proliferation risk if implemented right.
You build it, supply it with just about anything, including the waste from virtually any other reactor design, and then figurative seal it shut, with nothing radiological entering, and nothing leaving.
This means that all enterances and exits can have moderately sensitive radiation sensors.[1] The reprocessed fuel is highly radioactive, so it would not be feasible to sneak it out, since to encase it well enough to bypass the radiation sensors would be a major endeavor, which would be noticed (not to mention the difficulty of encasing the fuel without getting enough radiation on the case to make the case radioactive). Furthermore, if built with all the fuel already inside there would be no need to be able to disable the sensors when getting fuel, so the sensors could be designed to always trigger the alarms, no exceptions. Thus fuel cannot be sneaked out by first disabling the sensors.
It is not the IFR's reactor design that makes it so desirable. Any breeder reactor for which the following hold would be just as desirable: does not produce medium half-life waste, permits on-site reprocessing, and is able to use just about anything (waste from other reactors, plain (non-enriched) uranium, plain thorium, etc).
Footnotes: [1] Too sensitive of sensors may be triggered by the reactor itself, or by clothing or people/clothing who have become ever so slightly radioactive (at a level that causes no safety concern). The radiation sensors that the DHS has tried using on highways and in airports have proven too sensitive for their purposes.
You pay $15/4 GB, and this is not on top of some existing $X/month plan for voice service? If it is on top of an existing plan, then the details of the base plan must be known, since the cost of the voice plan certainly does factor in.
It can be easier on some phones. I've heard a few unsubstanciated reports of phones that had speed dial 9 default to 911. On most cell phones, a single digit speed dial number can be dialled simply by pressing and holding that digit for long enough.
There is also the 112 GSM standard, which would redirect to 911. Both of those I believe are required to connect even if they are just a prefix to a longer (invalid) number. Of course, with cell phones, the entire number is transmitted at once, so it would be possible to support some numbers that happen to be prefixes of other numbers. [1]
Lastly thanks to the ability to determine if a number is complete or a prefix when dialed on a cell phone, the cellular provider can support emergency numbers from other countries, including those that would not normally be permitted here, since they are valid prefixes of other numbers.
Asides: [1] The traditional system can also support that, by checking for a long enough pause, but that is considered somewhat unreliable. The pause is actually optional, since a "#" key as part of a DTMF dialing sequence is interpreted as "End of number", allowing the system to immediately dispatch the call, instead of waiting to see if more digits are forthcoming.
Much of the "linux" code seems to cover libelf, a library written for the explicit purpose of API level compatibility with SVR4. It covers both Michael Riepe's implementation of the library, as well as RedHat's implementation. The shared API means that functions with identical names and signatures, as well as quite a few API defined constant values. The names for structure feilds larely derives from the elf specification, so similarities there should also be expected.
tab 422: A function that returns a member of a structure passed in by reference, where the name of the necessary structure element is apparently not part of the API. It returns -1 if passed a null pointer. The linux version has a function with the same name and same signature, but that is no surprise. It checks for a null pointer using a different idiom than SVR4.2, and the name of the returned structure member is different. The "linux" code also has an assertion call, as well as explicitly casts the member to the correct datatype. In other words, the "linux" code is as different from the SVR 4.2 code as C code permits! (As long as you only consider C code with remotely reasonable coding standards).
Tab421 is covering a function to get the next item in what is effectively a linked list. It is actually surprising to me how different the code is, despite performing such a simple function. The only lines that are the same are those returning constants defined in the header as part of the API.
Tab 420 covers a three line function, returning a header defined constant if passed a null pointer, or an element of the passed structure. The only unusual similarity is that the argument uses the same name, but the function name strongly suggests using that name as the argument name. The structure field name is similar, but not identical, and is based on the name in the ELF specification.
Tab419 covers a different implementation of the same function, this time by redhat's libelf.
Tab418 shows annother "copied" 3 liner, where the "linux" implementation is a one-liner utilizing the ternary operator. This is one time where some copying may have occured, namely it looks like the function may have been copied, sans the body, and somebody else implemented the body. The reason I suspect this, is because the redhat implementation is using old K&R style argument definitions, like the SVR4 code, despite most of the redhat code using ANSI style argument definitions. Nevertheless, even if that had been copied, it is 4 lines of code, of which two are only curly braces.
This just keeps going on and on. Basically he was checking for any similarly named files that contained any code that looked similar, and alleging that said similarity indicates copyright infringement. He has no understanding of API's and how those naturally create similarity, and how such similarity has already been determined in past cases not to be considered copyright infringement.
Agreed. There are a few places where you could pay $10 a month for a car's data on top of your existing celluar plan, which in that event must already be overpriced, but that $10 would forbid any form of tethering, and would have fine print that limits total amount of usage, perhaps by hours rather than bytes, something like 90 hours a month being 3 hours a day, which is a bit more time than most people spend in a car, especially one you consider most people don't commute on weekends.
On one hand I I agree with the idea of short copyright lifespans, with a fixed time limit that is simply not open to negotiation, I feel 7 years may be rather hard to justify.
For musical works it may seem reasonable, but on the other hand, it does not really seem entirely reasonable for the first 5 Harry potter books to be public domain, which implies that not only would the books be freely available online, and dirt cheap copies in every bookstore, but that if the movie studios had waited only 4 additional years before filming the first movie, they could have cut J.K. Rowling out entirely for the whole series, as long as they released new movies on the same sort of schedule as she released the books.
For another perspective the first 3 seasons of Stargate SG-1 would have been freely available before the series even concluded!
Now, if you used a term of say 14 years, I would find the whole thing much more palatable. I would find it odd that Windows 95 would be in the public domain now, but only odd. Stargate SG-1 would have had four years after the series conclusion before the initial episodes would become public domain.
If Warner Brothers had wanted to cut J.K. Rowling out completely, they would have needed to wait until next year before they could start filming the first movie. That feels about right. By that point the popularity of the series would have died down so much the studio would indisputably have lost more money by waiting than by paying royalties to film sooner.
Actually, Neon would theoretically work, because Ne still has a lower atomic mass than N_2. Granted though that Neon is going to remain even more rare than Helium for the foreseeable future, so I'm not sure that is a step in the right direction. Neon though is very much non-reactive, so besides the scarcity it would be an ideal substitute for Helium.
The last time airships powered by vacuum were attempted it was found that the then current technology could not create a container strong enough to support a 1 atmosphere pressure differential without weighing enough to cancel out all the displaced air, preventing any buoyancy. Modern technology might be able to do better, but this is not guaranteed.
Indeed. While many complain about abuses of javascript, I've seen several sites that use it as part of AJAX that really improve the experience. I would strongly advise that people browse using a javascript blocking blacklist, rather than a whitelist.
Further more, some do use version numbers that are effectively decimals.
For example order the following versions: 1.11 1.2 1.1
I've seen some projects where the correct order would be 1.1, 1.11, 1.2, and others where the correct order is 1.1, 1.2, 1.11.
It varies significantly. Even having three components does not fix things. 1.1.5, 1.11.3, and 1.2.9 could be the correct order (albeit this sort of ordering is not common) or 1.1.5, 1.2.9, 1.11.3 could be the correct order.
One simply needs to be familiar with the scheme used by the software in question.
Trim has both purposes. If you trim a large file, it may have several physical erasable blocks become blank, thus allowing the drive to erase those whole physical blocks when idle, allowing fast writing to those physical blocks. It also tells it which of the logical blocks in a physical block are considered garbage, allowing the drive to skip them when reading that block, when rewriting that group of logical blocks.
The second purpose becomes redundant if the file system uses larger sector sizes, and the OS also tells the device that it wants larger addressable blocks, matching the increased sector size. The first purpose remains useful, assuming it is not important to you that blocks not actively used remain intact.
I firmly belive that I am among the very few people who have played the entire half-life series, and yet have spent less than 10 minutes playing any source or goldsource multiplayer game.
I play RTS games solely for the single player campaigns. I would get bored with the skirmish mode very quickly, and have zero interest in the multiplayer mode.
Playing local multiplayer with friends is indeed fun, but I don't have any friends over (pretty much ever), so I generally find that pretty worthless.
Andy why do you need admin privileges? To install a kernel-mode driver! Even the admin users cannot directly trap CTRL-ALT-DELETE and the right to install new services/Drivers can be restricted even for administrator accounts (but in practice never is).
Hell yes! I want move #43 from that disc, but they send me the whole thing, complete with 49 bundled crap movies, exactly like how albums often have only one or two decent songs and the rest is junk.
Thanks to the monstrous copy protection system likely in use by then, a single unreadability bit anywhere on the disk, will prevent playing every title. Furthermore, The system will be so terribly sensitive to minor scratches that merely putting the disk in the player will have a 50% chance of rending the disc valueless.
It would just be so much easier to stream 50 3D surround-picture films via the successor to bit-torrent over my stolen satellite down-link, thank-you-very-much!
Chrome currently has "phantom tabs". They are pinned tabs that have been closed. They show up in the tab bar just like all other pinned tabs, but they are slightly translucent, to distinguish them from other pinned tabs. They have no attached rendering engine, so the only resources they consume are those needed to display the favicon. But click on it, and a rendering engine is spawned, and the tab acts just like any other.
Thus when made phantom they would qualify as super-lightweight. Granted that currently it is only experimental, and the tabs do not reopen in phantom state but regular pinned-tab state, but that is coming.
Similarly, this tab-candy extension is looking at releasing the resources of tabs that have not been used recently n a similar fashion.
Primer's timeline though is extremely complicated, and does rely on a discrete metatime interpretation of time travel. Furthermore, the only person who apparently has a verified (by the film's author) correct timeline for the film has an explanation that is unreadable, because it was written defensively to ward off specific arguments against specific points, which new readers are completely unfamiliar with.
In case you are not being facetious, the vast majority of Japanese indie games that get localized for US release are pornographic.
It is to the point where if they did not specify it was a localization of a non-pornographic title, people would assume it was a pornographic title.
I know of hundreds of US-localized pornographic Japanese indie titles, but less than a dozen US-localized Japanese non-pornographic indie titles.
A simple circular polarization filter over the top of an LCD results in light that can be viewed in any angle through regular (linear) polarized glasses. This is not commonly found because the extra layer hurts contrast somewhat and also costs more, but You do see it in some places.
Really all versions? Going all the way back to 1.0, and also including the CE versions? I strongly doubt that! Perhaps it dates all the way back to NT4, but that is still very, very different than affecting all Windows versions.
Or there will be a plague in eastern Florida of sharks or elephants or whatever it is that eats turtles.
[[Sea turtle#Importance to humans]]
A plague of humans in eastern Florida? I'm afraid it is a bit late to worry about that!
I believe there may be more than one type of e-Fuse.
Most processors have special fuses, which can be set only once, at the factory, usually via jtag, that are set to disable any components of the processor that are not working, embed the unique serial number, etc. On setting a bit, the chip is physically changed, so it cannot be reset. We used to call this PROM technology, but I have seen the label eFuse used for it before.
The UltraSparc chips for example have an array of poly fuses that can be blown by an electrical pulse, which is used to store data configuring the system to avoid any defective subcores, etc, as well as specifying the serial number Sun called this part of the chip the eFuse.
Then there is the technology currently in question, which sounds to me more like configuration bits stored in EEPROM, like the "fuses" of a PIC microcontroller, which are specified in the bitfile downloaded to the processor, which can be reset via JTAG.
Honestly, yes. It allows for rapid development, the end code is all too often unmaintainable, and it is among the easier Turing-complete web technologies to learn. (Granted the programing languge itself is a superset of ECMAscript, so Javascript experience transfers partially, but browser DOM experience, and cross-browser coding experience does not really help.)
Unlike VB, the underlying language is actually reasonably good. It is an ECMAscript superset, as I already mentioned, so it is a prototype-based language. Like all decent dynamic languages ECMAscript (and thus both Javascript and Actionscript) permits procedural, object-oriented, and even functional programming paradigms. However, the extensions to ECMAscript include more traditional OO support than ECMAscript alone provides, making it possible to avoid many of the unusual idioms javascript OO design requires.
One interesting feature of Actionscript is the optional static typing. While the language is fundamentally dynamically typed, it provides the option of specifying static types on variables and function/method arguments. This primarily allows for better optimization, but also allows for better static analysis, including "compile-time" checking for certain kinds of type errors.
Thus a program can initially be designed using dynamicly typed variables for ease and speed of initial development, and later be slowly migrated to static typing during maintenance, providing the benefits of "compile-time" type-checking, as well as performance benefits. Even then, it is not necessary to commit to being fully statically typed, letting one leave dynamic those parts of the code that would benefit from that.
Thus the language itself is not one that an experienced developer would feel constrained in, nor would it be one they would feel embarrassed to use (which is very different to VB).
Java can be used for games, no doubt about it, but those type of games you are mentioning can have most of the code written before you even decide on the specifics of the game.
They are not as experimental as most flash games.
Flash lets you through together a game quickly to test a game-play mechanic, while the java game will probably be more technically solid, but would take more time to develop. Most of my favorite flash games would be many times harder to write in Java.
On the other hand, Java can definitely handle more than flash. Flash's 3D handling is rather primitive (but has been improving in the latest releases), and Flash does have slower code execution than Java, so code-heavy games (chess games, flight sims, etc) would also benefit from Java over Flash.
Java applets work, but the language is somewhat clunky[1], at least compared to flash, and for the longest time there were no good libraries for creating Java applet games. On the other hand, Flash was designed for animations and interactive animations, meaning it came by default with many of the necessary tools for building a game.
Indeed to this day, most flash games are developed from scratch, rather than using a pre-existing game library, even though several exist.
Java is also not as widely installed on home systems as Flash is.
Footnotes:
[1] In this context by clunky I mean that it does not permit many quick and dirty hacks that many scripting languages permit, tending to enforce at least some elements of proper OO design (although admittedly not all of them). In some contexts this is a good thing, as it discourages the quick and dirty hacks. However for game development, permitting the hacks can allow a developer to quickly try out an idea, and implement it properly only once it has been shown to be workable.
As long as the developer is disciplined enough to replace the hack with proper code, this can speed up testing out ideas without causing the code quality to suffer. If the hack is not replaced, this
Actually, "library" can and does mean "collection of" in English. Indeed that is the exact meaning of "library" in a "code library". Alone "library" implies a collection of books, but "music library" and similar terms are definitely in use.
"Library" when used alone may imply a lending library. Context is necessary to determine if lending library or book collection was intended. When used with modifiers, lending library is usually not implied, with a few exceptions, like "public library".
The only issue with your post is that because this is Slashdot, people may assume that "library" means code library in such a context, rather than "collection of". Thus it may be clearer to explicitly say collection.
Yes. The integral fast reactor design is very nice.
The key to the design is that it can burn just about anything, repeatedly through reprocessing, leaving only short half life and long half life waste.
Short half life waste is extremely dangerous, but can decay to safe levels in only 200-400 years, as opposed to the around 10,000 years the waste from traditional reactors is often quoted at. Long half-life waste, such as that found in the IFR waste is not a significant radiation concern.
Much of stuff could safely be held in your hand, not unlike uranium ore. Granted like uranium ore, prolonged exposure should be avoided, but brief exposures to significant sized chunks of long-halflife waste is not particularly worrying.
It is the medium half-life wastes in the output of most reactors that are really concerning. The half life is long enough that the material takes a really long time to decay to safe levels, while the half-life is also short enough that the waste is highly dangerous.
On annother note, the IFR is breeder reactor, but it is one of very few breeder-based designs that pose absolutely no real proliferation risk if implemented right.
You build it, supply it with just about anything, including the waste from virtually any other reactor design, and then figurative seal it shut, with nothing radiological entering, and nothing leaving.
This means that all enterances and exits can have moderately sensitive radiation sensors.[1] The reprocessed fuel is highly radioactive, so it would not be feasible to sneak it out, since to encase it well enough to bypass the radiation sensors would be a major endeavor, which would be noticed (not to mention the difficulty of encasing the fuel without getting enough radiation on the case to make the case radioactive). Furthermore, if built with all the fuel already inside there would be no need to be able to disable the sensors when getting fuel, so the sensors could be designed to always trigger the alarms, no exceptions. Thus fuel cannot be sneaked out by first disabling the sensors.
It is not the IFR's reactor design that makes it so desirable. Any breeder reactor for which the following hold would be just as desirable: does not produce medium half-life waste, permits on-site reprocessing, and is able to use just about anything (waste from other reactors, plain (non-enriched) uranium, plain thorium, etc).
Footnotes:
[1] Too sensitive of sensors may be triggered by the reactor itself, or by clothing or people/clothing who have become ever so slightly radioactive (at a level that causes no safety concern). The radiation sensors that the DHS has tried using on highways and in airports have proven too sensitive for their purposes.
You pay $15/4 GB, and this is not on top of some existing $X/month plan for voice service?
If it is on top of an existing plan, then the details of the base plan must be known, since the cost of the voice plan certainly does factor in.
It can be easier on some phones. I've heard a few unsubstanciated reports of phones that had speed dial 9 default to 911. On most cell phones, a single digit speed dial number can be dialled simply by pressing and holding that digit for long enough.
There is also the 112 GSM standard, which would redirect to 911. Both of those I believe are required to connect even if they are just a prefix to a longer (invalid) number. Of course, with cell phones, the entire number is transmitted at once, so it would be possible to support some numbers that happen to be prefixes of other numbers. [1]
Lastly thanks to the ability to determine if a number is complete or a prefix when dialed on a cell phone, the cellular provider can support emergency numbers from other countries, including those that would not normally be permitted here, since they are valid prefixes of other numbers.
Asides:
[1] The traditional system can also support that, by checking for a long enough pause, but that is considered somewhat unreliable. The pause is actually optional, since a "#" key as part of a DTMF dialing sequence is interpreted as "End of number", allowing the system to immediately dispatch the call, instead of waiting to see if more digits are forthcoming.
Indeed. Let's review some of it.
Much of the "linux" code seems to cover libelf, a library written for the explicit purpose of API level compatibility with SVR4. It covers both Michael Riepe's implementation of the library, as well as RedHat's implementation. The shared API means that functions with identical names and signatures, as well as quite a few API defined constant values. The names for structure feilds larely derives from the elf specification, so similarities there should also be expected.
tab 422: A function that returns a member of a structure passed in by reference, where the name of the necessary structure element is apparently not part of the API. It returns -1 if passed a null pointer. The linux version has a function with the same name and same signature, but that is no surprise. It checks for a null pointer using a different idiom than SVR4.2, and the name of the returned structure member is different. The "linux" code also has an assertion call, as well as explicitly casts the member to the correct datatype. In other words, the "linux" code is as different from the SVR 4.2 code as C code permits! (As long as you only consider C code with remotely reasonable coding standards).
Tab421 is covering a function to get the next item in what is effectively a linked list. It is actually surprising to me how different the code is, despite performing such a simple function. The only lines that are the same are those returning constants defined in the header as part of the API.
Tab 420 covers a three line function, returning a header defined constant if passed a null pointer, or an element of the passed structure. The only unusual similarity is that the argument uses the same name, but the function name strongly suggests using that name as the argument name. The structure field name is similar, but not identical, and is based on the name in the ELF specification.
Tab419 covers a different implementation of the same function, this time by redhat's libelf.
Tab418 shows annother "copied" 3 liner, where the "linux" implementation is a one-liner utilizing the ternary operator. This is one time where some copying may have occured, namely it looks like the function may have been copied, sans the body, and somebody else implemented the body. The reason I suspect this, is because the redhat implementation is using old K&R style argument definitions, like the SVR4 code, despite most of the redhat code using ANSI style argument definitions. Nevertheless, even if that had been copied, it is 4 lines of code, of which two are only curly braces.
This just keeps going on and on. Basically he was checking for any similarly named files that contained any code that looked similar, and alleging that said similarity indicates copyright infringement. He has no understanding of API's and how those naturally create similarity, and how such similarity has already been determined in past cases not to be considered copyright infringement.
Agreed. There are a few places where you could pay $10 a month for a car's data on top of your existing celluar plan, which in that event must already be overpriced, but that $10 would forbid any form of tethering, and would have fine print that limits total amount of usage, perhaps by hours rather than bytes, something like 90 hours a month being 3 hours a day, which is a bit more time than most people spend in a car, especially one you consider most people don't commute on weekends.
On one hand I I agree with the idea of short copyright lifespans, with a fixed time limit that is simply not open to negotiation, I feel 7 years may be rather hard to justify.
For musical works it may seem reasonable, but on the other hand, it does not really seem entirely reasonable for the first 5 Harry potter books to be public domain, which implies that not only would the books be freely available online, and dirt cheap copies in every bookstore, but that if the movie studios had waited only 4 additional years before filming the first movie, they could have cut J.K. Rowling out entirely for the whole series, as long as they released new movies on the same sort of schedule as she released the books.
For another perspective the first 3 seasons of Stargate SG-1 would have been freely available before the series even concluded!
Now, if you used a term of say 14 years, I would find the whole thing much more palatable. I would find it odd that Windows 95 would be in the public domain now, but only odd. Stargate SG-1 would have had four years after the series conclusion before the initial episodes would become public domain.
If Warner Brothers had wanted to cut J.K. Rowling out completely, they would have needed to wait until next year before they could start filming the first movie. That feels about right. By that point the popularity of the series would have died down so much the studio would indisputably have lost more money by waiting than by paying royalties to film sooner.
Actually, Neon would theoretically work, because Ne still has a lower atomic mass than N_2. Granted though that Neon is going to remain even more rare than Helium for the foreseeable future, so I'm not sure that is a step in the right direction. Neon though is very much non-reactive, so besides the scarcity it would be an ideal substitute for Helium.
The last time airships powered by vacuum were attempted it was found that the then current technology could not create a container strong enough to support a 1 atmosphere pressure differential without weighing enough to cancel out all the displaced air, preventing any buoyancy. Modern technology might be able to do better, but this is not guaranteed.
Indeed. While many complain about abuses of javascript, I've seen several sites that use it as part of AJAX that really improve the experience. I would strongly advise that people browse using a javascript blocking blacklist, rather than a whitelist.
Further more, some do use version numbers that are effectively decimals.
For example order the following versions:
1.11
1.2
1.1
I've seen some projects where the correct order would be 1.1, 1.11, 1.2, and others where the correct order is 1.1, 1.2, 1.11.
It varies significantly. Even having three components does not fix things. 1.1.5, 1.11.3, and 1.2.9 could be the correct order (albeit this sort of ordering is not common) or 1.1.5, 1.2.9, 1.11.3 could be the correct order.
One simply needs to be familiar with the scheme used by the software in question.
Trim has both purposes. If you trim a large file, it may have several physical erasable blocks become blank, thus allowing the drive to erase those whole physical blocks when idle, allowing fast writing to those physical blocks. It also tells it which of the logical blocks in a physical block are considered garbage, allowing the drive to skip them when reading that block, when rewriting that group of logical blocks.
The second purpose becomes redundant if the file system uses larger sector sizes, and the OS also tells the device that it wants larger addressable blocks, matching the increased sector size. The first purpose remains useful, assuming it is not important to you that blocks not actively used remain intact.