Aside from the very relevant link the parent posted, if you walk away from a contract the other party is only entitled to actual economic damages. So long as your new product isn't competing with your old employer and you haven't taken any of their IP (it's a felony to steal IP), then they haven't lost any money and aren't entitled to a cent in damages.
Not entirely true -- they could demand an order of specific performance to have your IP transferred to them.
You have opinions, which is nice. The original poster has a contract, signed and legal, which can be used to take whatever the employer desires from the employee.
Not necessarily. Depending on jurisdiction, there are variety of laws that limit what employers can include in employment contracts. If the term is covered by one of those laws, it's invalid, and OP is free to ignore it. For this reason, he needs to talk to a local employment law specialist.
The person I was responding to was recommending truecrypt for entire-hard-disk encryption. I don't think many of us have hard disks in our machines that we don't write to.
You are arguing that you don't need to bother checking if a valid object comes back because it won't throw up a runtime error. Wow, let's just push the error identification onto the user then, right?
This is not an error condition that could plausibly occur at the user level. For it to happen, the referenced element would have to not be defined on the page, yet the page completed loading without error. Any form of acceptance testing will catch the possibility of such a condition before deployment.
And even if it does, what's the cost? A feature stops working, gracefully, because the method used to integrate it into the page was intentionally one based on the principle of graceful degradation. The controls to hide blocks of text don't get added, so the user can no longer do this. This is clearly not the end of the world, and it would probably be worse to bother the user with an error message than do nothing.
The rest of the arguments simply expose that you're not used to creating re-usable software components, or you're being disingenuous in your examples. You act as if you should be using this in the non-anymous function, you shouldn't. Everything used in that function should be passed to it unless it is a global exposed by a framework you are using.
Doing so would requires 10 or 20 lines of code defining new objects, setting fields in them to appropriate values, and generally associating objects with their dependencies, along with creating functions that call back to methods in those objects via closures (not an inbuilt feature of the language, unfortunately, as the language is designed to use closures in places where other languages might use callback objects). As you're a software engineer, I assume that you're aware of the finding that the cost of code both in terms of time to originally write and time required for maintenance over the life of the project is proportional to the number of lines, regardless of how many features those lines implement? You've just multiplied the cost of this little feature by 3-6 times.
Your really poor function attempts are indeed unclear in their operation because that's how you wrote them (again, presumably on purpose rather than through incompetence.)
He wrote them that way because that is the natural way of writing them in the environment. How do *you* write javascript callback functions? The typical OO approach of putting them in an object simply doesn't work properly because of the fact that js callbacks are in many cases not made to the object you expect. This problem is hardly unique to jquery, or indeed my code.
Why? What is the negative consequence of doing so. If the function only needs to be referenced once, what is wrong with defining it where it will be referenced? It is more direct, and makes the action of the call to click() clearer.
Don't perform evaluations in your return statements.
Why? In what way is this:
var newElement = $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })}); return newElement;
Avoid calling methods/functions on objects via the return of another evaluator.
Why? The API is a fluent API, specifically designed to allow this. Why not use this feature? Are you saying that respected programming writers like (e.g.) Joshua Bloch and Martin Fowler are wrong to recommend this style?
The code sample he provided is counter to reusability
I'd say it's very reusable: I can simply include this code fragment on any page I want hideable elements on, and it's reused. If necessary, I can wrap it in a function. If I wanted to make it more reusable, it wouldn't be hard to turn it into a jquery plugin, so then all I'd need to do is $(".hideable").addHideControl();
But in the end, how reusable do you need a 3-line code fragment that was written in less than 5 minutes to be?
readability
There are a lot of people who'd disagree with you there. Yes, you need to be vaguely familiar with jquery to understand what I wrote, but if you aren't familiar with the tools I'm using, what are you doing trying to maintain my code?
unsafe in that it doesn't evaluate possible nulls
There are no possible nulls. $(selector) is defined to always return a result set (which is possibly empty). The clone() method always returns a copy of the object set it was called on. The click() method always returns the object it was called on.
and arguably impossible to debug
I was debugging very similar code only yesterday, and didn't find it even remotely difficult.
I also agree that it can be very simple, but it is also equally simple for it to not be an anonymous function. Is it as "easy" as doing it anonymously? No. Is it better from an engineering practices standpoint? Yes. Writing test cases for anonymous functions seems likely to be 'challenging';).
Writing test cases for a nested function is likely to be just as challenging, yet the function I wrote *must* be nested, because it is required to have access to a copy of an outer-function local variable. That function can't be moved to an outer scope because it is necessary that the variable is bound to the instance of function invocation (i.e. it is a closure).
I'm yet to hear one good argument why the function shouldn't be defined inline. Just dogma saying not to do it. Well... justify it.
The code that was given was, imho, the antithesis of what a software engineer should produce. Does it mean it doesn't work? No. Does it mean it isn't clever? No. Does it mean it is buggy? No. It is, however, poor software engineering.
I contend that you're only saying that because you're unfamiliar with the environment. To anyone who knows it more than moderately well, what I wrote is clear, obvious, and the natural way of doing it. What other way should it be done?
LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.
C++, by its very nature, depends on word sizes. This simple program cannot be implemented by a compiler that is word size agnostic:
int bytemasks[sizeof(int)]; int main(void) {
for (int i = 0; i < sizeof(bytemasks); i++)
bytemasks[i] = 0xFF<<(i*8); }
The compiler must know how many bytes are in the words used by the architecture in order to know how much memory to allocate to the bytemasks array. This cannot be determined at runtime because the C++ specification requires bytemasks to have an exported address that is known at link time. Deferring the decision to the linker is too complex, as it could theoretically require the linker to evaluate arbitrary expressions.
In the end, the simple fact is that the complaints the author of the email you cite raises about LLVM are necessary, because it would be impossible to efficiently implement C-like languages without them. LLVM supports executing non-typesafe code, the same as C does. LLVM adapts the available integer and FP types to those supported by the target processor, the same as C does. By necessity this means there are platform-dependent variations in it.
What this does not mean (as you notice) is that it's impossible to use LLVM as a virtual machine. Go ahead and define your own virtual platform using it, with specified datatypes and endianness, and then use it to produce output code for a native platform (either ahead-of-time or just-in-time) that works with those types. It is simple to write LLVM plugins that modify data access to allow you to (for example) support big-endian ints on little-endian machines. All of this is entirely possible, and has been done. The only problem is that performance is ludicrously bad.
There are some solutions: you could write an LLVM analyser that detects which variables might be accessed outside of standard alignment (i.e., only those to which pointers are take and where those pointers are passed to code that might perform arithmetic on them using incorrect word lengths, or which feature in unions) and only performs endianness-correction on those. This would help a little, at least. For some programs it would help a lot.
Or you could use a type safety checker that ensures all pointers are only ever treated as pointers to the correct type, and no casts from one pointer type to a type with different size ever happen. This would restrict the class of programs you can run, but would allow you to ignore endianness as a constraint. Validated programs for your virtual platform could then be run directly on any processor supporting your chosen int/float sizes without modification.
You could simply ignore endianness as an issue. Pick one, and then let the VM->native compiler assume the native layout. Programs that perform inappropriate pointer conversions produce undefined behaviour. This wouldn't violate either the C or C++ spec, but is perhaps undesirable for a portable VM system.
Note that these three solutions to the problem are the only ones possible: anything else would involve violations of the C/C++ specs, and therefore the resulting VM wouldn't support those languages.
None of this solves the fundamental problem with doing this for the web, though, which is that LLVM doesn't provide sandboxed execution. It does not guarantee type safety (although type safety can be added on to it relatively easily, at least for some definitions of safety, again restricting the class of programs you can run) or memory safety (i.e. preventing accesses via freed pointers, local variables in expired stack frames, or out-of-bounds array accesses, which is a harder problem to solve), so it is impossible to guarantee that code running on it does not perform unauthorised actions.
Stop using jquery and you'll find that half of your headaches are gone automatically. Javascript can brain-dead simple if you know how to use it -- and it can be a gigantic headache when you use it incorrectly. If you think jquery makes your life easier, you're clearly using it wrong.
Sorry. I cannot agree here. Jquery enables some of the most elegant web programming I have ever seen. It allows, among other things, almost total separation of program logic from content -- I can use an entirely declarative approach on content elements that I want to be active, and then have a separate.js file to hook up the declarations and the actual logic behind them, trivially:
(doing this from memory, untested, but I'm pretty sure it'll work)
Do that in three lines of code without jquery or another of the libraries you claim to despise. Hell, do it in 30. For reference -- it finds the element with id 'showhidecontrol' from the existing document and places deep copies of it before each element with class 'hideable', adding an onclick event handler to it that adds the class 'hidden' to the element with class 'hideable' if it isn't already present, or removes it if it is.
Yes. How do you think it prevents the mounted primary fs from overwriting the contents of the hidden volume? It only knows the hidden volume is there if you provide its password. If you don't, the data in it can be overwritten, so writing to the primary is a dangerous operation. The OS provides no method for preventing it from attempting to overwrite the hidden partition, so all it does is report a write error if you try to do so. This is not a condition most file system drivers are good at handling, and can easily lead to filesystem corruption.
Why do radio equipment manufacturers always neglect the lower frequency bands? 150kHz minimum? What if I want to listen in on 125kHz RFID transmissions? How about picking about radio clock signals (usually in the range 50kHz-75kHz, depending on location)? Would it really have made the board that much more expensive to support these frequencies?
I admit, I'm biased, but why do you view a MIPS core as a negative?
It isn't as suited as ARM to embedded applications, mainly due to a 32-bit instruction length vs 16-bit for ARM thumb. You get much higher code density on ARM. Also, MIPS SoCs are almost universally not superscalar (whereas ARM Cortex SoCs like the one the Pi is based on are) and often lack floating point capabilities (but I believe all(?) ARM cores have integral FP).
Truecrypt hidden volumes are too inconvenient for actual use on drives that see day-to-day use. You need to put in two passwords every time you mount, and you run the risk of the OS attempting to write to the space used by the hidden volume and having an error reported by the truecrypt driver, which is likely to lead to corruption of files on the primary system. At least it's no longer true that you have to use a FAT filesystem on your primary, which you did last time I tried to use one.
Consipracy to commit copyright infringement and profiting from it are two completely different things. For it to be conspiracy, there must be a few additional boxes ticked:
- the copyright infringement was criminal (not all copyright infringement is, for example there are no known cases where contributory infringement has been held to be criminal) - the accused must have agreed with somebody else that they would perform the infringement - the accused must then have taken some action that enabled that performance
Simply profiting from piracy only requires the last of these three conditions. Presumably there was criminal copyright infringement taking place, but I have not seen any evidence of any form of coordination between the operators of the site and the people who performed this infringement, which would be needed to prove the second condition.
Ahem... except... you should look up the actual statistics. We have not been experiencing an increase in extreme weather.
Certainly, as news has become more global we have learned about more extreme weather events, but when you look at the actual statistics, there has not been any increase. There just hasn't. In fact, hurricane and typhoon activity have been at a 40-year low.
Your data appears to be incorrect. This data appears to show a roughly steady number of moderate duration storms (albeit with dips in the 20s and 80s), but with an increasing trend in short duration storms. The 2000-2008 period was a 100-year high. AIUI, long-duration storms are a rare enough event that there isn't adequate data to draw conclusions from them.
Try to find: Dripps RD, Comroe JH (1947) Respiratory and circulatory response of normal man to inhalation of 7.6 and 10.4 per cent CO2 with a comparison of the maximal ventilation produced by severe muscular exercise, inhalation of CO2 and maximal voluntary hyperventilation. American Journal of Physiology 149, 43–51
They found that a single inhalation of 7-10% CO2 causes noticeable symptoms of respiratory distress. I'm not sure what effect that kind of exposure for an hour would have, but I'm pretty certain it wouldn't be pleasant.
Please don't take me wrong, I agree with you about the bias of the author. However I would like to point out that generally asbestos sheets are harmless when left alone. Once you start cutting it and creating dust particles out of it then it most definitely is a carcinogen. So, while Allegre was probably wrong to oppose the removal of asbestos what people might be missing is the fact that it is doing things with the asbestos (eg routine renovating or the removal) that could release the carcinogenic particles.
The asbestos in question was a sprayed powder-coating of the building's walls, not stabilized sheet material. In this circumstance, ordinary use of the building is likely to cause fibres to be released (e.g. when walls are accidentally scraped or bumped). This kind of use is widely considered to be dangerous enough to warrant immediate removal.
They other thing they said is that glass fiber insulating material (here they go by the trade name, "Pink Batts") has the same problem as asbestos - actually inert, and safe when left, but creating dust can cause all sorts of probems, including leading to lung cancer/illness.
Then they were either wrong, being overly cautious, or bullshitting you. Glass fibre with diameter > 3 microns cannot enter the respiratory system and cause issues in the way asbestos does. Asbestos molecules can cleave lengthways, resulting in the fibre's diameter decreasing when it is turned to dust, and therefore asbestos fibres cannot be guaranteed to be greater than any particular size. Glass fibre cannot cleave in this way, so if it is manufactured at a large enough size (and glass fibre insulation is) it is safe. It is classified as an irritant, but is not carcinogenic. Studies of the health of glass fibre workers show no noticeable increase in cancer incidence. With asbestos workers, the increase in incidence is so high that even the Romans noticed it among their slaves.
When it's 100F or above, it's so hot that sweat isn't enough. When it's 0F or below, it would be a good idea to limit time outside, and at 10F or below, keep your insulated water lines flowing because insulation is insufficient. The Celcius equivs are harder to remember: 37.777...., -17.77..., -12.22...
Your 100F is nowhere near as accurate as you think it is. 36C (about 97F) is probably much closer to the mark. For 10F you're talking about a vague rule-of-thumb that also depends on diameter of pipe, type and thickness of insulation, how frequently it's used under normal circumstances, and the temperature of water that flows through it when it is used. In the right circumstances, an insulated pressurized pipe can freeze at any temperature below about -5C. I'd personally start thinking about such things for domestic water pipes that are in frequent use at temperatures below -10C.
I hate to stop your wonderful support of my country, but cheeses wise we have about 3, and feck the rest from France:o)
Whaddya mean?!
We have Cheddar, Scottish cheddar, Scottish Highland cheddar, Scottish Island cheddar, Welsh cheddar, cheddar from other places... we'll even claim Canadian cheddar as our own if you give us half a chance!
Oh, and more seriously: Cheshire, Shropshire, Wensleydale, Stilton, Caerphilly, Y-fenwi, Yarg, and of course Brie (most of which is made in Somerset).
If the French banned export of cheese tomorrow, I confess I'd miss Roquefort. Other than that, they can keep em!:)
Yes, but nowhere near as much as that. To pick a random example, "Digital SLR Photography" has a cover price of £4, whereas a subscription gives you 12 issues for £43.
OTOH, GP was perhaps exaggerating in saying price was on par with a paperback book, as these seem to typically be about £7. Yes, I am aware that they're cheaper in the US -- publishing is one of the few markets where there seems to be a real price disparity between the two countries. Importers typically charge £1 per dollar cover price of US editions, which probably leaves quite a bit of space for profit, especially as they're almost certainly getting >50% discount from the publishers. I suspect the reason for the difference is economy of scale -- the UK is a market only about a fifth the size of the US, and the cost of printing stuff like this is almost entirely in the per-issue set-up costs.
The average satellite costs $97M to build and $51M to launch (source: Euroconsult 10-year satellite forecast, 2009), so "micro" would still be more appropriate (the units being about 500 milli-satellites from this perspective, I'll allow them to get away with a factor of two exaggeration).
And personally, I prefer to apply vi over nano, but whatever - I'm not one of "them".
Jed all the way, for me. With a bit of kate thrown in for good measure.
The term/product you didn't know to google for is "schmartboard" aka http://www.schmartboard.com/ [schmartboard.com] They have about a zillion competitors, some doing their own thing, some just ripping off the schmartboard guys.
You buy a tiny little PCBs where you solder your SOIC or SOT or whatever device to the tiny PCB and the other edge of the PCB is precision designed to connect to standard pitch protoboards or whatever, using header strips or short wires. You can think of it (heck some are marketed as) a SOIC to DIP adapter board
Oh, sure, I've seen a whole load of this kind of stuff. Problem is, it's all too expensive. A piece of stripboard for a moderately simple project (24 tracks x 37 holes) costs me about £1, whereas a board to accommodate, say, a PLCC40 or similar chip will typically costs £5 or more. For SOIC you may be able to get them as cheap as £3 or thereabouts. Which is to say, in most cases, the board is actually more expensive than the chip itself.
Slashdot Mirror
Aside from the very relevant link the parent posted, if you walk away from a contract the other party is only entitled to actual economic damages. So long as your new product isn't competing with your old employer and you haven't taken any of their IP (it's a felony to steal IP), then they haven't lost any money and aren't entitled to a cent in damages.
Not entirely true -- they could demand an order of specific performance to have your IP transferred to them.
You have opinions, which is nice. The original poster has a contract, signed and legal, which can be used to take whatever the employer desires from the employee.
Not necessarily. Depending on jurisdiction, there are variety of laws that limit what employers can include in employment contracts. If the term is covered by one of those laws, it's invalid, and OP is free to ignore it. For this reason, he needs to talk to a local employment law specialist.
The person I was responding to was recommending truecrypt for entire-hard-disk encryption. I don't think many of us have hard disks in our machines that we don't write to.
Your code doesn't work on Internet Explorer prior to version 9, or Firefox prior to version 3. The jquery code I posted will work on IE6 or Firefox 1.
You are arguing that you don't need to bother checking if a valid object comes back because it won't throw up a runtime error. Wow, let's just push the error identification onto the user then, right?
This is not an error condition that could plausibly occur at the user level. For it to happen, the referenced element would have to not be defined on the page, yet the page completed loading without error. Any form of acceptance testing will catch the possibility of such a condition before deployment.
And even if it does, what's the cost? A feature stops working, gracefully, because the method used to integrate it into the page was intentionally one based on the principle of graceful degradation. The controls to hide blocks of text don't get added, so the user can no longer do this. This is clearly not the end of the world, and it would probably be worse to bother the user with an error message than do nothing.
The rest of the arguments simply expose that you're not used to creating re-usable software components, or you're being disingenuous in your examples. You act as if you should be using this in the non-anymous function, you shouldn't. Everything used in that function should be passed to it unless it is a global exposed by a framework you are using.
Doing so would requires 10 or 20 lines of code defining new objects, setting fields in them to appropriate values, and generally associating objects with their dependencies, along with creating functions that call back to methods in those objects via closures (not an inbuilt feature of the language, unfortunately, as the language is designed to use closures in places where other languages might use callback objects). As you're a software engineer, I assume that you're aware of the finding that the cost of code both in terms of time to originally write and time required for maintenance over the life of the project is proportional to the number of lines, regardless of how many features those lines implement? You've just multiplied the cost of this little feature by 3-6 times.
Your really poor function attempts are indeed unclear in their operation because that's how you wrote them (again, presumably on purpose rather than through incompetence.)
He wrote them that way because that is the natural way of writing them in the environment. How do *you* write javascript callback functions? The typical OO approach of putting them in an object simply doesn't work properly because of the fact that js callbacks are in many cases not made to the object you expect. This problem is hardly unique to jquery, or indeed my code.
Don't define functions inline of your statement.
Why? What is the negative consequence of doing so. If the function only needs to be referenced once, what is wrong with defining it where it will be referenced? It is more direct, and makes the action of the call to click() clearer.
Don't perform evaluations in your return statements.
Why? In what way is this:
var newElement = $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});
return newElement;
clearer than
return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});
?
Avoid calling methods/functions on objects via the return of another evaluator.
Why? The API is a fluent API, specifically designed to allow this. Why not use this feature? Are you saying that respected programming writers like (e.g.) Joshua Bloch and Martin Fowler are wrong to recommend this style?
The code sample he provided is counter to reusability
I'd say it's very reusable: I can simply include this code fragment on any page I want hideable elements on, and it's reused. If necessary, I can wrap it in a function. If I wanted to make it more reusable, it wouldn't be hard to turn it into a jquery plugin, so then all I'd need to do is $(".hideable").addHideControl();
But in the end, how reusable do you need a 3-line code fragment that was written in less than 5 minutes to be?
readability
There are a lot of people who'd disagree with you there. Yes, you need to be vaguely familiar with jquery to understand what I wrote, but if you aren't familiar with the tools I'm using, what are you doing trying to maintain my code?
unsafe in that it doesn't evaluate possible nulls
There are no possible nulls. $(selector) is defined to always return a result set (which is possibly empty). The clone() method always returns a copy of the object set it was called on. The click() method always returns the object it was called on.
and arguably impossible to debug
I was debugging very similar code only yesterday, and didn't find it even remotely difficult.
I also agree that it can be very simple, but it is also equally simple for it to not be an anonymous function. Is it as "easy" as doing it anonymously? No. Is it better from an engineering practices standpoint? Yes. Writing test cases for anonymous functions seems likely to be 'challenging' ;).
Writing test cases for a nested function is likely to be just as challenging, yet the function I wrote *must* be nested, because it is required to have access to a copy of an outer-function local variable. That function can't be moved to an outer scope because it is necessary that the variable is bound to the instance of function invocation (i.e. it is a closure).
I'm yet to hear one good argument why the function shouldn't be defined inline. Just dogma saying not to do it. Well... justify it.
The code that was given was, imho, the antithesis of what a software engineer should produce. Does it mean it doesn't work? No. Does it mean it isn't clever? No. Does it mean it is buggy? No. It is, however, poor software engineering.
I contend that you're only saying that because you're unfamiliar with the environment. To anyone who knows it more than moderately well, what I wrote is clear, obvious, and the natural way of doing it. What other way should it be done?
LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.
C++, by its very nature, depends on word sizes. This simple program cannot be implemented by a compiler that is word size agnostic:
int bytemasks[sizeof(int)];
int main(void) {
for (int i = 0; i < sizeof(bytemasks); i++)
bytemasks[i] = 0xFF<<(i*8);
}
The compiler must know how many bytes are in the words used by the architecture in order to know how much memory to allocate to the bytemasks array. This cannot be determined at runtime because the C++ specification requires bytemasks to have an exported address that is known at link time. Deferring the decision to the linker is too complex, as it could theoretically require the linker to evaluate arbitrary expressions.
In the end, the simple fact is that the complaints the author of the email you cite raises about LLVM are necessary, because it would be impossible to efficiently implement C-like languages without them. LLVM supports executing non-typesafe code, the same as C does. LLVM adapts the available integer and FP types to those supported by the target processor, the same as C does. By necessity this means there are platform-dependent variations in it.
What this does not mean (as you notice) is that it's impossible to use LLVM as a virtual machine. Go ahead and define your own virtual platform using it, with specified datatypes and endianness, and then use it to produce output code for a native platform (either ahead-of-time or just-in-time) that works with those types. It is simple to write LLVM plugins that modify data access to allow you to (for example) support big-endian ints on little-endian machines. All of this is entirely possible, and has been done. The only problem is that performance is ludicrously bad.
There are some solutions: you could write an LLVM analyser that detects which variables might be accessed outside of standard alignment (i.e., only those to which pointers are take and where those pointers are passed to code that might perform arithmetic on them using incorrect word lengths, or which feature in unions) and only performs endianness-correction on those. This would help a little, at least. For some programs it would help a lot.
Or you could use a type safety checker that ensures all pointers are only ever treated as pointers to the correct type, and no casts from one pointer type to a type with different size ever happen. This would restrict the class of programs you can run, but would allow you to ignore endianness as a constraint. Validated programs for your virtual platform could then be run directly on any processor supporting your chosen int/float sizes without modification.
You could simply ignore endianness as an issue. Pick one, and then let the VM->native compiler assume the native layout. Programs that perform inappropriate pointer conversions produce undefined behaviour. This wouldn't violate either the C or C++ spec, but is perhaps undesirable for a portable VM system.
Note that these three solutions to the problem are the only ones possible: anything else would involve violations of the C/C++ specs, and therefore the resulting VM wouldn't support those languages.
None of this solves the fundamental problem with doing this for the web, though, which is that LLVM doesn't provide sandboxed execution. It does not guarantee type safety (although type safety can be added on to it relatively easily, at least for some definitions of safety, again restricting the class of programs you can run) or memory safety (i.e. preventing accesses via freed pointers, local variables in expired stack frames, or out-of-bounds array accesses, which is a harder problem to solve), so it is impossible to guarantee that code running on it does not perform unauthorised actions.
Stop using jquery and you'll find that half of your headaches are gone automatically. Javascript can brain-dead simple if you know how to use it -- and it can be a gigantic headache when you use it incorrectly. If you think jquery makes your life easier, you're clearly using it wrong.
Sorry. I cannot agree here. Jquery enables some of the most elegant web programming I have ever seen. It allows, among other things, almost total separation of program logic from content -- I can use an entirely declarative approach on content elements that I want to be active, and then have a separate .js file to hook up the declarations and the actual logic behind them, trivially:
$(".hideable").before(function () {
var hideableElement = this;
return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});
(doing this from memory, untested, but I'm pretty sure it'll work)
Do that in three lines of code without jquery or another of the libraries you claim to despise. Hell, do it in 30. For reference -- it finds the element with id 'showhidecontrol' from the existing document and places deep copies of it before each element with class 'hideable', adding an onclick event handler to it that adds the class 'hidden' to the element with class 'hideable' if it isn't already present, or removes it if it is.
Yes. How do you think it prevents the mounted primary fs from overwriting the contents of the hidden volume? It only knows the hidden volume is there if you provide its password. If you don't, the data in it can be overwritten, so writing to the primary is a dangerous operation. The OS provides no method for preventing it from attempting to overwrite the hidden partition, so all it does is report a write error if you try to do so. This is not a condition most file system drivers are good at handling, and can easily lead to filesystem corruption.
Haven't tested it, really. Only ever use it in the same room as my router, but it works reliably there.
Why do radio equipment manufacturers always neglect the lower frequency bands? 150kHz minimum? What if I want to listen in on 125kHz RFID transmissions? How about picking about radio clock signals (usually in the range 50kHz-75kHz, depending on location)? Would it really have made the board that much more expensive to support these frequencies?
And with no wifi built in, that means using a usb device hanging out the side.
I have one of these in my laptop. The thing protrudes less than a centimetre; it hardly "hangs".
I admit, I'm biased, but why do you view a MIPS core as a negative?
It isn't as suited as ARM to embedded applications, mainly due to a 32-bit instruction length vs 16-bit for ARM thumb. You get much higher code density on ARM. Also, MIPS SoCs are almost universally not superscalar (whereas ARM Cortex SoCs like the one the Pi is based on are) and often lack floating point capabilities (but I believe all(?) ARM cores have integral FP).
The model A still has USB, so who needs integrated ethernet? You can attach whatever you need to it that way.
Truecrypt hidden volumes are too inconvenient for actual use on drives that see day-to-day use. You need to put in two passwords every time you mount, and you run the risk of the OS attempting to write to the space used by the hidden volume and having an error reported by the truecrypt driver, which is likely to lead to corruption of files on the primary system. At least it's no longer true that you have to use a FAT filesystem on your primary, which you did last time I tried to use one.
Consipracy to commit copyright infringement and profiting from it are two completely different things. For it to be conspiracy, there must be a few additional boxes ticked:
- the copyright infringement was criminal (not all copyright infringement is, for example there are no known cases where contributory infringement has been held to be criminal)
- the accused must have agreed with somebody else that they would perform the infringement
- the accused must then have taken some action that enabled that performance
Simply profiting from piracy only requires the last of these three conditions. Presumably there was criminal copyright infringement taking place, but I have not seen any evidence of any form of coordination between the operators of the site and the people who performed this infringement, which would be needed to prove the second condition.
Ahem... except... you should look up the actual statistics. We have not been experiencing an increase in extreme weather.
Certainly, as news has become more global we have learned about more extreme weather events, but when you look at the actual statistics, there has not been any increase. There just hasn't. In fact, hurricane and typhoon activity have been at a 40-year low.
Your data appears to be incorrect. This data appears to show a roughly steady number of moderate duration storms (albeit with dips in the 20s and 80s), but with an increasing trend in short duration storms. The 2000-2008 period was a 100-year high. AIUI, long-duration storms are a rare enough event that there isn't adequate data to draw conclusions from them.
Try to find: Dripps RD, Comroe JH (1947) Respiratory and circulatory response of normal man to inhalation of 7.6 and 10.4 per cent CO2 with a comparison of the maximal ventilation produced by severe muscular exercise, inhalation of CO2 and maximal voluntary hyperventilation. American Journal of Physiology 149, 43–51
They found that a single inhalation of 7-10% CO2 causes noticeable symptoms of respiratory distress. I'm not sure what effect that kind of exposure for an hour would have, but I'm pretty certain it wouldn't be pleasant.
Please don't take me wrong, I agree with you about the bias of the author. However I would like to point out that generally asbestos sheets are harmless when left alone. Once you start cutting it and creating dust particles out of it then it most definitely is a carcinogen. So, while Allegre was probably wrong to oppose the removal of asbestos what people might be missing is the fact that it is doing things with the asbestos (eg routine renovating or the removal) that could release the carcinogenic particles.
The asbestos in question was a sprayed powder-coating of the building's walls, not stabilized sheet material. In this circumstance, ordinary use of the building is likely to cause fibres to be released (e.g. when walls are accidentally scraped or bumped). This kind of use is widely considered to be dangerous enough to warrant immediate removal.
They other thing they said is that glass fiber insulating material (here they go by the trade name, "Pink Batts") has the same problem as asbestos - actually inert, and safe when left, but creating dust can cause all sorts of probems, including leading to lung cancer/illness.
Then they were either wrong, being overly cautious, or bullshitting you. Glass fibre with diameter > 3 microns cannot enter the respiratory system and cause issues in the way asbestos does. Asbestos molecules can cleave lengthways, resulting in the fibre's diameter decreasing when it is turned to dust, and therefore asbestos fibres cannot be guaranteed to be greater than any particular size. Glass fibre cannot cleave in this way, so if it is manufactured at a large enough size (and glass fibre insulation is) it is safe. It is classified as an irritant, but is not carcinogenic. Studies of the health of glass fibre workers show no noticeable increase in cancer incidence. With asbestos workers, the increase in incidence is so high that even the Romans noticed it among their slaves.
When it's 100F or above, it's so hot that sweat isn't enough. When it's 0F or below, it would be a good idea to limit time outside, and at 10F or below, keep your insulated water lines flowing because insulation is insufficient. The Celcius equivs are harder to remember: 37.777...., -17.77..., -12.22...
Your 100F is nowhere near as accurate as you think it is. 36C (about 97F) is probably much closer to the mark. For 10F you're talking about a vague rule-of-thumb that also depends on diameter of pipe, type and thickness of insulation, how frequently it's used under normal circumstances, and the temperature of water that flows through it when it is used. In the right circumstances, an insulated pressurized pipe can freeze at any temperature below about -5C. I'd personally start thinking about such things for domestic water pipes that are in frequent use at temperatures below -10C.
>a couple of thousand different cheeses
I hate to stop your wonderful support of my country, but cheeses wise we have about 3, and feck the rest from France :o)
Whaddya mean?!
We have Cheddar, Scottish cheddar, Scottish Highland cheddar, Scottish Island cheddar, Welsh cheddar, cheddar from other places ... we'll even claim Canadian cheddar as our own if you give us half a chance!
Oh, and more seriously: Cheshire, Shropshire, Wensleydale, Stilton, Caerphilly, Y-fenwi, Yarg, and of course Brie (most of which is made in Somerset).
If the French banned export of cheese tomorrow, I confess I'd miss Roquefort. Other than that, they can keep em! :)
Yes, but nowhere near as much as that. To pick a random example, "Digital SLR Photography" has a cover price of £4, whereas a subscription gives you 12 issues for £43.
OTOH, GP was perhaps exaggerating in saying price was on par with a paperback book, as these seem to typically be about £7. Yes, I am aware that they're cheaper in the US -- publishing is one of the few markets where there seems to be a real price disparity between the two countries. Importers typically charge £1 per dollar cover price of US editions, which probably leaves quite a bit of space for profit, especially as they're almost certainly getting >50% discount from the publishers. I suspect the reason for the difference is economy of scale -- the UK is a market only about a fifth the size of the US, and the cost of printing stuff like this is almost entirely in the per-issue set-up costs.
Perhaps the context for the prefix was its cost?
The average satellite costs $97M to build and $51M to launch (source: Euroconsult 10-year satellite forecast, 2009), so "micro" would still be more appropriate (the units being about 500 milli-satellites from this perspective, I'll allow them to get away with a factor of two exaggeration).
And personally, I prefer to apply vi over nano, but whatever - I'm not one of "them".
Jed all the way, for me. With a bit of kate thrown in for good measure.
The term/product you didn't know to google for is "schmartboard" aka
http://www.schmartboard.com/ [schmartboard.com]
They have about a zillion competitors, some doing their own thing, some just ripping off the schmartboard guys.
You buy a tiny little PCBs where you solder your SOIC or SOT or whatever device to the tiny PCB and the other edge of the PCB is precision designed to connect to standard pitch protoboards or whatever, using header strips or short wires. You can think of it (heck some are marketed as) a SOIC to DIP adapter board
Oh, sure, I've seen a whole load of this kind of stuff. Problem is, it's all too expensive. A piece of stripboard for a moderately simple project (24 tracks x 37 holes) costs me about £1, whereas a board to accommodate, say, a PLCC40 or similar chip will typically costs £5 or more. For SOIC you may be able to get them as cheap as £3 or thereabouts. Which is to say, in most cases, the board is actually more expensive than the chip itself.