If this goes ahead, carriers will not "unlock" phones. Rather, carriers will not "lock" phones. There is a difference between inherent restrictions and artificial restrictions.
I'm still getting along fine with my OpenMoko FreeRunner. It's currently running Debian, so it's as scriptable as anything. The "programming environment which runs on desktops or laptops" is whatever you use already; the "plugs right in" part is SSH (and its friends scp, sshfs, etc.).
So, either you love OpenMoko and hence your wish is fulfilled, or you see it as a total failure in which case it's clear why nobody is doing this anymore.
it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies.
Well then, how do we explain the common practice of using magic numbers in cryptography standard, then?
I think the word "magic" is being used with two different meanings here. One meaning is "arbitrary but consistent": those numbers which must be standardised, such as the SHA seeds used to find these curves. The other meaning is "chosen for completely unknown reasons", which describes these particular seed values. The former is a requirement of most cryptographic standards, but the latter should be avoided. If we need to consistently choose an arbitrary number, let it be 1, or pi, or e. Anything else is suspicious.
Getting a package into Debian is hard, but it's perfectly acceptable to release Debian packages standalone alongside your tarballs, or to host your own repository. The package format itself is pretty simple, and making them can be as easy as arranging your files, writing a few lines in a control file and running "dpkg-deb -b". I do this when I make changes to my system, since it makes them easy to undo.
The 50 page guides are for Debian's own standards, which you must follow to get a package into Debian. If you're providing it from your site, you don't have to follow them at all, although they contain good advice. Also note that the guides contains lots of optional sections: if your program doesn't use Python, Perl, compilation, setuid, etc. then you can skip those sections.
Lambdas can only contain one expression, but that expression can have side effects. For example, we can wrap statements up into functions (which they should be anyway), we can call these functions from inside a tuple (the elements in a tuple are guaranteed to be evaluated in order) and we can get mutable local state by pushing and popping the elements of a list.
Many languages now compile to Javascript. Some are specifically designed for this (TypeScript, Dart, Elm), others have gained it later, especially thanks to emscripten.
The DOM can still be a pain, since it's difficult to abstract away. There are those who abandon the DOM altogether, eg. using Canvas or WebGL. That brings its own concerns though (especially accessibility).
There's an interesting talk from Chaos Communication Camp 2011 about making a verified PDF scanner in the Coq proof assistant: http://www.youtube.com/watch?v=CmPw7eo3nQI
observation of position disturbs momentum and vice versa
That's the observer effect, which TFA seems to be talking about. The observer effect implies that there is an exact position and momentum; particles can be little billiard-balls if we like, but any attempt to measure them will disturb them.
The uncertainty principle, as it is currently understood, says that there is no such thing as an exact position or momentum. Particles are wave-packets in force-fields. When we introduce quantum constraints, eg. the integral of (area under) the wave packet is some discrete amount, the uncertainty principle falls out naturally.
It's easiest to imagine the case close to zero. For example, having a near-certain position means not being spread out in space. To maintain the constant area, this requires a large amplitude. Likewise a near-zero amplitude must be spread out in space to make up the same area. This is position/momentum uncertainty.
If we want a packet of near-zero duration (eg. a Dirac delta), then we need to build up lots of Fourier terms, which spreads out the overall wavelength. Likewise, if we want a precise wavelength, we need to get closer to a pure sine wave, but that means we get a longer and longer duration (a completely pure sine wave would last forever). That's basically the energy/time uncertainty.
the uncertainty principle states that it is impossible to simultaneously know the exact position and momentum of a subatomic particle
I find phrases like this misleading. I think it's more intellectually honest to say something along the lines of:
the uncertainty principle states that position and momentum are not independent quantities, but (incompatible) expressions of a more fundamental property.
Popsci keeps claiming that 'everything we thought knew is wrong' based on the slightest whiff of a strange experimental result, yet when quantum mechanics *does* prove wrong everything we thought we knew (like the concepts of position and momentum), with repeated experiments of incredible precision, popsci clings to those old notions and acts like QM is wacky.
Just bad coding. Any language can be coded with badly. (some more easily or accidentally than others)
"Bad coding" is similar to "no true Scotsman"; the goalposts are movable in hindsight. What really matters is how easily we can spot potentially-insecure code when we're browsing a codebase *before* it is exploited.
Let's say our codebase contains, somewhere deep inside, a C function which tramples over unallocated memory. How likely are we to spot this bug as a maintainer, who may occasionally open the file for unrelated purposes? Not very, since unsafe C code looks pretty-much the same as safe C code.
Likewise our codebase could contain a PHP function with an XSS vulnerability. How likely are we to spot that? Again, not very.
Now let's say our codebase contains a PHP function which tramples over unallocated memory (via PHP, not due to some buggy C library). How likely are we to spot that? Very likely, since it would appear pretty bizarre, even if it weren't buggy. This makes PHP more memory-safe than C.
The underlying reason PHP is unsafe when it comes to Web programming is that it treats everything as strings. User input, SQL queries, HTTP headers, HTML, regular expressions, filenames, code, variable/class/method/constant/function names and so on. Implicit conversion even allows non-strings to be treated as strings. With everything implemented as a strings, programmers think of their data as strings instead of what they actually are (HTML attributes, unsafe external input, etc.). This leads to string-based interfaces, which beget more string-based interfaces in the name of compatibility, and any non-string interfaces (eg. SimpleXML) end up with string-based escape hatches which force us to carry on thinking in terms of strings. When everything is a string, nobody knows what their data actually *is*. Has this SQL query come from the outside world? You'd better hope not, since you've just sent it to the database!
The really twisted part is that, in a world of strings, the "solution" to security is escaping. Actually escaping is just a symptom; escaping a string just gives us another string! We gain no information by escaping; we go from data that's potentially unsafe to data that's potentially garbage (double-escaped). What's the solution to the double-escaping problem? Remove some escaping! Escaping must be done exactly once, but good programming practice makes us split up our applications into many small, reusable pieces. This means that the vast majority of any codebase *cannot* escape its data, for fear of double-escaping. Thus the majority of our code must either trust that its input is safe, or trust that someone else will escape its output for us. This is the case no matter how security-minded we are.
However, the nature of programming is to plug other people's things together in ways they didn't anticipate. Doing otherwise would just be reinventing the wheel. No wonder that form inputs get plugged straight into databases! The input-reading functions are compatible with the database-querying functions! Why should I worry about security when the functions I'm using have been written by the world's foremost security-minded PHP programmers? They know more about this stuff than I do, so I'd rather plug their stuff together than put my own naive code in between!
This ecosystem is why PHP is more-unsafe than, for example, Java (which is less-unsafe), Haskell (which is even-less-unsafe) and Agda (which is much-less-unsafe).
In a system where different languages have their own specific types, we can't just plug a form input into a database. We need to convert an "UnsafeInput" into an "SQL"; the path of least resistance would be to use an escape function. There's also no danger of double-escaping, since an escaping function can't consume its own output without it getting converted back first. Such undesirable outcomes are still *possible*, but require manually working-around the provided mechanisms. Such co
You got it wrong, I say, and it is because of this:
The benefits of this stuff are IMMEDIATE.
It won't particularly matter that a quick brain-zap will make me a great violinist when my hands are unusable due to arthritis. Similarly, if bi-annual brain-zapping helps boost memory, it won't matter once mine's already gone.
For example, there is next to ZERO "opportunity-cost" of waiting: Since, as usual in this world, only 1% of the exact methods attempted will end up being beneficial, the other 99% will not be. On the other hand, if something turns out to be truly beneficial, I can implement those methods IMMEDIATELY, without delay.
There is an opportunity cost to waiting, which is clear from my examples above. Yes I can choose to join-in in 10 years time, but I can never go back and improve the 10 years I missed out on.
You are talking genes, but the article (and I) are talking METHODS used by individuals.
...
Or, trying to understand what/how you think, do you think this is about "brain zapping" turning into genetic advantages? This would be strange, since - this is not what we've been talking about AFAICS - the only thing natural selection can do *here* on genes is to let you SURVIVE those electric charges. Anyone who already survives or would survive will get any benefits immediately by just doing the same thing.
I mentioned genes because you mentioned natural selection. My point is that a lifetime of long-term study won't help you and I as individual organisms (we will die by the time it's done, by the definition of "lifetime"), but it will benefit our offspring (who will hopefully outlive us). This gives us (humans in general) another evolutionary advantage against other species.
However, aside from the continuation of the species, I *also* care about my own limited life as a bag of meat. If I can zap myself smarter then I may be able to achieve more of my goals in life. The older I get, the less potential I have. Zapping myself into a super-genius on my death bed is pretty pointless; although, of course, it may be my death bed precisely *because* I zapped my brain in it;)
So I'm all for it, since I'll sit at the sidelines at let other people be the lab rats to find the 0.0001% of stuff that actually works and is useful (longterm).
That's fine for your genes, but by the time a large sample of subjects have been studied over a long time-scale, the results will be pretty useless to you and I as organisms. Except perhaps some symptom-relieving benefits for dementia.
Deciding not to participate is still a decision, and the opportunity-cost of waiting must be taken into account.
The collision energies are ~10 % of LHC's. The benefit of a linear collider is that leptons like electrons and positrons can be used, making the analysis of the collisions simpler.
The LHC's predecessor was the "Large Electron Positron" collider, so that's not a particular reason to use a linear accelerator.
Lepton accelerators do have an advantage over baryon colliders in that leptons are (as far as we can tell) indivisible; if you smash two leptons together with X amount of energy each, you get a collision of energy 2X. With baryons, the energy of each is mostly divided up between their three constituent quarks. Colliding two baryons usually results in a collision between one quark from each, so your collisions only use about 1/3 of the energy that was put in.
I agree. "Computer club" should not be "code-monkey training"; the point is to engage and play, not to teach practical job skills.
Keep as far away from the stereotypes as possible, eg. don't show a screen full of unintelligible symbols for doing something with numbers.
Make it easily accessible, eg. drag and drop, sliders, concrete results rather than abstract results, difficult/impossible to make syntax errors (eg. tile-based languages).
Make it lenient. Getting a parameter wrong in a procedural image generator can produce an incorrect result which is still interesting. An error message is not an interesting result.
Make it give instant gratification. Once I create a PacMan sprite I should be able to hook it up to the keyboard and play; I shouldn't have to stub out a Level class, a Ghost class, a setPowerPillDeactivateTimeOut method, etc.
There are many programming environments which use direct manipulation rather than code. Some examples are eToys, Scratch and LivelyKernel (the latter two will run in a browser). If you want to write some code you could try those which are designed to be easy for kids to learn, eg. LOGO (lots of versions available) and Smalltalk (Amber will run Smalltalk in the browser). Find and read some of the studies by Seymore Papert, Alan Kay, etc. into teaching kids programming. There are also some less-general, domain-specific languages which make it easy to get an immediate 'wow' factor, eg. PureData.
Make sure the projects have a multimedia element (graphical, musical, etc). Make sure things are relatable (games, crawling a popular Web site, etc.). Make a big list of ideas and take a vote for what one/two the group should do together at a time.
There are plenty of areas where free software is very important, such as basic computing infrastructure like compilers, operating systems, networking, web standards, and audio/video decoders. But instead they are focusing on the script that makes text blink on some random website.
Hundreds of millions of users are sacrificing their Freedom to, for example, Facebook and Google's Javascript, which is running on their machines for hour after hour, every single day. Are there hundreds of millions of users running compilers for hour after hour every day? Last I checked, Gentoo wasn't that popular. Free Software is about Freedom for computer users. "Computer users" is not restricted to developers who want to throw together some existing royalty-free libraries to make YetAnotherWalledGardenDataSilo.com. In fact, they're the minority, and they're actively working to undermine the Freedom of everyone else.
The examples you cite as "basic computing infrastructure" are very important, but they also have many mature Free implementations. I spend most of my time on my laptop which uses OpenFirmware, Debian (without non-free), MPlayer, NetSurf and Emacs. That's most bases covered. If I visited a Javascript-powered Web site in a Javascript-enabled browser, I would probably lose some of that Freedom. Hence this campaign.
While I understand why they've taken this position, "The Internet" != "WWW". Increasingly content producers are publishing content through app stores because apps provide content creators with a piece of mind that distribution across the DRM free web does not.
We will get to see the result of the grand experiment of publishing content on the web versus through apps. Content follows the money. If there is more money to be generated distributing content over a DRM free web, that's where it will stay. But if there is more money to be made distributing it through locked down apps on locked down platforms - well there's no reason to think that people won't abandon any technology as quickly as they adopt it if the content that they want to view migrates somewhere else.
That's fine with me, but the major difference is that those who want the DRM should have to pay for it, either by developing and maintaining it or by paying someone to do so. DRM is a Red Queen's race; you have to run as fast as you can just to stay where you are. Universal, Sony, etc. want to stay where they are without running the race, so they're trying ride in a sedan chair carried by browser developers.
"I find X to be strange" is another way of saying "I'm pretending that I live in a magical, X-free fantasy world.". There is no such fantasy world and never has been. Nature doesn't care if your brain is mis-configured.
When we get a result that's unexpected, we have an opportunity to deepen our understanding. That's science. When we get a result that's "strange", we're being contrary to our own knowledge. That's not science; I'd say it's more like religion.
True, and the show also covered much more than Astrophysics. For example its claims that the brain operates using symbolic logic seem dated, since these days we would say the brain is more about statistics. It also covered evolutionary biology and microbiology, fields which have progressed tremendously in recent decades.
I suppose that's the problem when one tries to cover such a broad subject as the Cosmos;)
I was dropped from my school's GCSE IT program. Now I have a Master's degree in Physics with Computer Science, where all of my projects have been computational, and I am a professional software developer and program Free Software in my spare time.
It's high time IT lessons got updated. I've heard that a decline in applications to computing courses at University correlated quite well to the introduction of IT curricula in schools. Learning about computers went from a mysterious, futuristic prospect to a mundane, mind-numbing exercise where the pupils are often far more competent than the teacher.
Also, the idea of learning things by exploring them seems to be lost to many school's IT staff. Harsh punishments were enacted on us for clicking anything in menus that weren't explicitly told to.
I find your comment a little self-contradictory. You say that being trained to use Word was meaningless, yet training them to use bash would be useful; and this given the fact that vastly more people use Word than bash.
I agree that computer skills are useful, but programming in C or Java would be a complete waste of time IMHO. All of the teaching time would be spent explaining the syntax for declaring types and, in the case of C, how to use pointers.
The language of choice should be Logo, which was designed specifically to help children think logically (see http://en.wikipedia.org/wiki/Seymour_Papert ). I did a little Logo in school, but it was largely superficial. It certainly beat the office training that came later.
Other systems that would be good to teach are Etoys, Scratch and Smalltalk, as these were all designed with children as the target audience and learning as the goal. Languages like Java and C are designed to be used by computer professionals to build large, real systems with acceptable performance, certain guarantees known at compile-time, etc. They're not good for teaching concepts; such things are overwhelmed by details, and are assumed to already be known by whoever is using the language.
I can't say what the XO-1.75 is like, but I do have an XO-1 that I use regularly.
The XO-1's UI is heavily written in Python and has a simplified IDE for Python installed by default. It also comes with the awesome Scratch and Etoys images for its customised Squeak Smalltalk VM. There's also a LOGO program by default, and a POSIX terminal (which itself is written in Python from what I can tell). Holding down the game keys while booting can also bring up the OpenFirmware console and a Game of Life simulator. I'd say there's a lot to be learned from those systems that is applicable to others, especially Scratch.
A nifty feature of the hardware is that the microphone socket can be used as a general purpose analogue input, which I'm sure would be useful for robotics applications (eg. sensor input).
Also, as far as landfill goes, the XO-1 was the "greenest" laptop ever made when it came out, and there is talk of a free recycling scheme (although I don't know if it ever materialised) http://sourceforge.net/search/?fq%5B%5D=trove%3A251 . The laptops are, obviously, extremely rugged, but even when they do break they are designed to be easy to strip down for parts (for example, the screen was engineered specifically to require no mercury). As far as being obsoleted goes, I think having a rental model would increase the sense of obsolescence, whilst having your own laptop that still runs after 10 years just as well as when it was first made, would give a sense of pride and familiarity to counteract the aggressive upgrade cycle that plagues the home computer world. As an example, my computing needs were served perfectly well by an Amiga 1200 for 10 years, and these XOs have resources an order of magnitude or two more than that.
It's a pretty amazing project, and I wish them the best of luck going forwards!
Slashdot Mirror
If this goes ahead, carriers will not "unlock" phones. Rather, carriers will not "lock" phones. There is a difference between inherent restrictions and artificial restrictions.
"Inside Job is a 2010 documentary film about the late-2000s financial crisis directed by Charles H. Ferguson."
Thanks for the link; do you think I'll be safe if I cash-out my investments by 2990? ;)
I'm still getting along fine with my OpenMoko FreeRunner. It's currently running Debian, so it's as scriptable as anything. The "programming environment which runs on desktops or laptops" is whatever you use already; the "plugs right in" part is SSH (and its friends scp, sshfs, etc.).
So, either you love OpenMoko and hence your wish is fulfilled, or you see it as a total failure in which case it's clear why nobody is doing this anymore.
it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies.
Well then, how do we explain the common practice of using magic numbers in cryptography standard, then?
I think the word "magic" is being used with two different meanings here. One meaning is "arbitrary but consistent": those numbers which must be standardised, such as the SHA seeds used to find these curves. The other meaning is "chosen for completely unknown reasons", which describes these particular seed values. The former is a requirement of most cryptographic standards, but the latter should be avoided. If we need to consistently choose an arbitrary number, let it be 1, or pi, or e. Anything else is suspicious.
Getting a package into Debian is hard, but it's perfectly acceptable to release Debian packages standalone alongside your tarballs, or to host your own repository. The package format itself is pretty simple, and making them can be as easy as arranging your files, writing a few lines in a control file and running "dpkg-deb -b". I do this when I make changes to my system, since it makes them easy to undo.
The 50 page guides are for Debian's own standards, which you must follow to get a package into Debian. If you're providing it from your site, you don't have to follow them at all, although they contain good advice. Also note that the guides contains lots of optional sections: if your program doesn't use Python, Perl, compilation, setuid, etc. then you can skip those sections.
Lambdas can only contain one expression, but that expression can have side effects. For example, we can wrap statements up into functions (which they should be anyway), we can call these functions from inside a tuple (the elements in a tuple are guaranteed to be evaluated in order) and we can get mutable local state by pushing and popping the elements of a list.
I wrote a rather rambly blog post about doing this http://chriswarbo.net/index.php?page=news&type=view&id=admin-s-blog%2Fanonymous-closures-in
The end result is an embedded domain-specific language (EDSL) for lambda calculus with de Bruijn indices, built using Python's numbers and lists.
Many languages now compile to Javascript. Some are specifically designed for this (TypeScript, Dart, Elm), others have gained it later, especially thanks to emscripten.
The DOM can still be a pain, since it's difficult to abstract away. There are those who abandon the DOM altogether, eg. using Canvas or WebGL. That brings its own concerns though (especially accessibility).
This kind of nonsense is exactly why I left Be when they were bought by Sky.
I'm now with Andrews & Arnold, who's registration process forces me to opt-out of any censorship http://aa.net.uk/kb-broadband-unfiltered.html
There's an interesting talk from Chaos Communication Camp 2011 about making a verified PDF scanner in the Coq proof assistant: http://www.youtube.com/watch?v=CmPw7eo3nQI
observation of position disturbs momentum and vice versa
That's the observer effect, which TFA seems to be talking about. The observer effect implies that there is an exact position and momentum; particles can be little billiard-balls if we like, but any attempt to measure them will disturb them.
The uncertainty principle, as it is currently understood, says that there is no such thing as an exact position or momentum. Particles are wave-packets in force-fields. When we introduce quantum constraints, eg. the integral of (area under) the wave packet is some discrete amount, the uncertainty principle falls out naturally.
It's easiest to imagine the case close to zero. For example, having a near-certain position means not being spread out in space. To maintain the constant area, this requires a large amplitude. Likewise a near-zero amplitude must be spread out in space to make up the same area. This is position/momentum uncertainty.
If we want a packet of near-zero duration (eg. a Dirac delta), then we need to build up lots of Fourier terms, which spreads out the overall wavelength. Likewise, if we want a precise wavelength, we need to get closer to a pure sine wave, but that means we get a longer and longer duration (a completely pure sine wave would last forever). That's basically the energy/time uncertainty.
Ironically, JSUIX contains Vi but not Emacs ;)
the uncertainty principle states that it is impossible to simultaneously know the exact position and momentum of a subatomic particle
I find phrases like this misleading. I think it's more intellectually honest to say something along the lines of:
the uncertainty principle states that position and momentum are not independent quantities, but (incompatible) expressions of a more fundamental property.
Popsci keeps claiming that 'everything we thought knew is wrong' based on the slightest whiff of a strange experimental result, yet when quantum mechanics *does* prove wrong everything we thought we knew (like the concepts of position and momentum), with repeated experiments of incredible precision, popsci clings to those old notions and acts like QM is wacky.
Not an unsafe language...
Just bad coding. Any language can be coded with badly. (some more easily or accidentally than others)
"Bad coding" is similar to "no true Scotsman"; the goalposts are movable in hindsight. What really matters is how easily we can spot potentially-insecure code when we're browsing a codebase *before* it is exploited.
Let's say our codebase contains, somewhere deep inside, a C function which tramples over unallocated memory. How likely are we to spot this bug as a maintainer, who may occasionally open the file for unrelated purposes? Not very, since unsafe C code looks pretty-much the same as safe C code.
Likewise our codebase could contain a PHP function with an XSS vulnerability. How likely are we to spot that? Again, not very.
Now let's say our codebase contains a PHP function which tramples over unallocated memory (via PHP, not due to some buggy C library). How likely are we to spot that? Very likely, since it would appear pretty bizarre, even if it weren't buggy. This makes PHP more memory-safe than C.
The underlying reason PHP is unsafe when it comes to Web programming is that it treats everything as strings. User input, SQL queries, HTTP headers, HTML, regular expressions, filenames, code, variable/class/method/constant/function names and so on. Implicit conversion even allows non-strings to be treated as strings. With everything implemented as a strings, programmers think of their data as strings instead of what they actually are (HTML attributes, unsafe external input, etc.). This leads to string-based interfaces, which beget more string-based interfaces in the name of compatibility, and any non-string interfaces (eg. SimpleXML) end up with string-based escape hatches which force us to carry on thinking in terms of strings. When everything is a string, nobody knows what their data actually *is*. Has this SQL query come from the outside world? You'd better hope not, since you've just sent it to the database!
The really twisted part is that, in a world of strings, the "solution" to security is escaping. Actually escaping is just a symptom; escaping a string just gives us another string! We gain no information by escaping; we go from data that's potentially unsafe to data that's potentially garbage (double-escaped). What's the solution to the double-escaping problem? Remove some escaping! Escaping must be done exactly once, but good programming practice makes us split up our applications into many small, reusable pieces. This means that the vast majority of any codebase *cannot* escape its data, for fear of double-escaping. Thus the majority of our code must either trust that its input is safe, or trust that someone else will escape its output for us. This is the case no matter how security-minded we are.
However, the nature of programming is to plug other people's things together in ways they didn't anticipate. Doing otherwise would just be reinventing the wheel. No wonder that form inputs get plugged straight into databases! The input-reading functions are compatible with the database-querying functions! Why should I worry about security when the functions I'm using have been written by the world's foremost security-minded PHP programmers? They know more about this stuff than I do, so I'd rather plug their stuff together than put my own naive code in between!
This ecosystem is why PHP is more-unsafe than, for example, Java (which is less-unsafe), Haskell (which is even-less-unsafe) and Agda (which is much-less-unsafe).
In a system where different languages have their own specific types, we can't just plug a form input into a database. We need to convert an "UnsafeInput" into an "SQL"; the path of least resistance would be to use an escape function. There's also no danger of double-escaping, since an escaping function can't consume its own output without it getting converted back first. Such undesirable outcomes are still *possible*, but require manually working-around the provided mechanisms. Such co
You got it wrong, I say, and it is because of this:
The benefits of this stuff are IMMEDIATE.
It won't particularly matter that a quick brain-zap will make me a great violinist when my hands are unusable due to arthritis. Similarly, if bi-annual brain-zapping helps boost memory, it won't matter once mine's already gone.
For example, there is next to ZERO "opportunity-cost" of waiting: Since, as usual in this world, only 1% of the exact methods attempted will end up being beneficial, the other 99% will not be. On the other hand, if something turns out to be truly beneficial, I can implement those methods IMMEDIATELY, without delay.
There is an opportunity cost to waiting, which is clear from my examples above. Yes I can choose to join-in in 10 years time, but I can never go back and improve the 10 years I missed out on.
You are talking genes, but the article (and I) are talking METHODS used by individuals.
Or, trying to understand what/how you think, do you think this is about "brain zapping" turning into genetic advantages? This would be strange, since
- this is not what we've been talking about AFAICS
- the only thing natural selection can do *here* on genes is to let you SURVIVE those electric charges. Anyone who already survives or would survive will get any benefits immediately by just doing the same thing.
I mentioned genes because you mentioned natural selection. My point is that a lifetime of long-term study won't help you and I as individual organisms (we will die by the time it's done, by the definition of "lifetime"), but it will benefit our offspring (who will hopefully outlive us). This gives us (humans in general) another evolutionary advantage against other species.
However, aside from the continuation of the species, I *also* care about my own limited life as a bag of meat. If I can zap myself smarter then I may be able to achieve more of my goals in life. The older I get, the less potential I have. Zapping myself into a super-genius on my death bed is pretty pointless; although, of course, it may be my death bed precisely *because* I zapped my brain in it ;)
So I'm all for it, since I'll sit at the sidelines at let other people be the lab rats to find the 0.0001% of stuff that actually works and is useful (longterm).
That's fine for your genes, but by the time a large sample of subjects have been studied over a long time-scale, the results will be pretty useless to you and I as organisms. Except perhaps some symptom-relieving benefits for dementia.
Deciding not to participate is still a decision, and the opportunity-cost of waiting must be taken into account.
The collision energies are ~10 % of LHC's. The benefit of a linear collider is that leptons like electrons and positrons can be used, making the analysis of the collisions simpler.
The LHC's predecessor was the "Large Electron Positron" collider, so that's not a particular reason to use a linear accelerator.
Lepton accelerators do have an advantage over baryon colliders in that leptons are (as far as we can tell) indivisible; if you smash two leptons together with X amount of energy each, you get a collision of energy 2X. With baryons, the energy of each is mostly divided up between their three constituent quarks. Colliding two baryons usually results in a collision between one quark from each, so your collisions only use about 1/3 of the energy that was put in.
I agree. "Computer club" should not be "code-monkey training"; the point is to engage and play, not to teach practical job skills.
Keep as far away from the stereotypes as possible, eg. don't show a screen full of unintelligible symbols for doing something with numbers.
Make it easily accessible, eg. drag and drop, sliders, concrete results rather than abstract results, difficult/impossible to make syntax errors (eg. tile-based languages).
Make it lenient. Getting a parameter wrong in a procedural image generator can produce an incorrect result which is still interesting. An error message is not an interesting result.
Make it give instant gratification. Once I create a PacMan sprite I should be able to hook it up to the keyboard and play; I shouldn't have to stub out a Level class, a Ghost class, a setPowerPillDeactivateTimeOut method, etc.
There are many programming environments which use direct manipulation rather than code. Some examples are eToys, Scratch and LivelyKernel (the latter two will run in a browser). If you want to write some code you could try those which are designed to be easy for kids to learn, eg. LOGO (lots of versions available) and Smalltalk (Amber will run Smalltalk in the browser). Find and read some of the studies by Seymore Papert, Alan Kay, etc. into teaching kids programming. There are also some less-general, domain-specific languages which make it easy to get an immediate 'wow' factor, eg. PureData.
Make sure the projects have a multimedia element (graphical, musical, etc). Make sure things are relatable (games, crawling a popular Web site, etc.). Make a big list of ideas and take a vote for what one/two the group should do together at a time.
There are plenty of areas where free software is very important, such as basic computing infrastructure like compilers, operating systems, networking, web standards, and audio/video decoders. But instead they are focusing on the script that makes text blink on some random website.
Hundreds of millions of users are sacrificing their Freedom to, for example, Facebook and Google's Javascript, which is running on their machines for hour after hour, every single day. Are there hundreds of millions of users running compilers for hour after hour every day? Last I checked, Gentoo wasn't that popular. Free Software is about Freedom for computer users. "Computer users" is not restricted to developers who want to throw together some existing royalty-free libraries to make YetAnotherWalledGardenDataSilo.com. In fact, they're the minority, and they're actively working to undermine the Freedom of everyone else.
The examples you cite as "basic computing infrastructure" are very important, but they also have many mature Free implementations. I spend most of my time on my laptop which uses OpenFirmware, Debian (without non-free), MPlayer, NetSurf and Emacs. That's most bases covered. If I visited a Javascript-powered Web site in a Javascript-enabled browser, I would probably lose some of that Freedom. Hence this campaign.
While I understand why they've taken this position, "The Internet" != "WWW". Increasingly content producers are publishing content through app stores because apps provide content creators with a piece of mind that distribution across the DRM free web does not.
We will get to see the result of the grand experiment of publishing content on the web versus through apps. Content follows the money. If there is more money to be generated distributing content over a DRM free web, that's where it will stay. But if there is more money to be made distributing it through locked down apps on locked down platforms - well there's no reason to think that people won't abandon any technology as quickly as they adopt it if the content that they want to view migrates somewhere else.
That's fine with me, but the major difference is that those who want the DRM should have to pay for it, either by developing and maintaining it or by paying someone to do so. DRM is a Red Queen's race; you have to run as fast as you can just to stay where you are. Universal, Sony, etc. want to stay where they are without running the race, so they're trying ride in a sedan chair carried by browser developers.
"I find X to be strange" is another way of saying "I'm pretending that I live in a magical, X-free fantasy world.". There is no such fantasy world and never has been. Nature doesn't care if your brain is mis-configured.
When we get a result that's unexpected, we have an opportunity to deepen our understanding. That's science. When we get a result that's "strange", we're being contrary to our own knowledge. That's not science; I'd say it's more like religion.
Astrophysics has really advanced since 1980.
True, and the show also covered much more than Astrophysics. For example its claims that the brain operates using symbolic logic seem dated, since these days we would say the brain is more about statistics. It also covered evolutionary biology and microbiology, fields which have progressed tremendously in recent decades.
I suppose that's the problem when one tries to cover such a broad subject as the Cosmos ;)
I was dropped from my school's GCSE IT program. Now I have a Master's degree in Physics with Computer Science, where all of my projects have been computational, and I am a professional software developer and program Free Software in my spare time.
It's high time IT lessons got updated. I've heard that a decline in applications to computing courses at University correlated quite well to the introduction of IT curricula in schools. Learning about computers went from a mysterious, futuristic prospect to a mundane, mind-numbing exercise where the pupils are often far more competent than the teacher.
Also, the idea of learning things by exploring them seems to be lost to many school's IT staff. Harsh punishments were enacted on us for clicking anything in menus that weren't explicitly told to.
I find your comment a little self-contradictory. You say that being trained to use Word was meaningless, yet training them to use bash would be useful; and this given the fact that vastly more people use Word than bash.
I agree that computer skills are useful, but programming in C or Java would be a complete waste of time IMHO. All of the teaching time would be spent explaining the syntax for declaring types and, in the case of C, how to use pointers.
The language of choice should be Logo, which was designed specifically to help children think logically (see http://en.wikipedia.org/wiki/Seymour_Papert ). I did a little Logo in school, but it was largely superficial. It certainly beat the office training that came later.
Other systems that would be good to teach are Etoys, Scratch and Smalltalk, as these were all designed with children as the target audience and learning as the goal. Languages like Java and C are designed to be used by computer professionals to build large, real systems with acceptable performance, certain guarantees known at compile-time, etc. They're not good for teaching concepts; such things are overwhelmed by details, and are assumed to already be known by whoever is using the language.
Oops! That link was meant to be http://www.olpcnews.com/laptops/xo1/olpc_xo_greenest_laptop_made.html
I can't say what the XO-1.75 is like, but I do have an XO-1 that I use regularly.
The XO-1's UI is heavily written in Python and has a simplified IDE for Python installed by default. It also comes with the awesome Scratch and Etoys images for its customised Squeak Smalltalk VM. There's also a LOGO program by default, and a POSIX terminal (which itself is written in Python from what I can tell). Holding down the game keys while booting can also bring up the OpenFirmware console and a Game of Life simulator. I'd say there's a lot to be learned from those systems that is applicable to others, especially Scratch.
A nifty feature of the hardware is that the microphone socket can be used as a general purpose analogue input, which I'm sure would be useful for robotics applications (eg. sensor input).
Also, as far as landfill goes, the XO-1 was the "greenest" laptop ever made when it came out, and there is talk of a free recycling scheme (although I don't know if it ever materialised) http://sourceforge.net/search/?fq%5B%5D=trove%3A251 . The laptops are, obviously, extremely rugged, but even when they do break they are designed to be easy to strip down for parts (for example, the screen was engineered specifically to require no mercury). As far as being obsoleted goes, I think having a rental model would increase the sense of obsolescence, whilst having your own laptop that still runs after 10 years just as well as when it was first made, would give a sense of pride and familiarity to counteract the aggressive upgrade cycle that plagues the home computer world. As an example, my computing needs were served perfectly well by an Amiga 1200 for 10 years, and these XOs have resources an order of magnitude or two more than that.
It's a pretty amazing project, and I wish them the best of luck going forwards!