I'm pretty sure EU consumer protection laws disallow this kind of practices. Yes, they can change what they like. No, I don't have to agree, which leads to termination of contract with no additional fees.
Get a used HTC Dream aka Google G1. Plus "extended battery".
1. They are on the market the longest, making their "hacker" support the most complete. Yes, they are alive and popular, new Cyanogen versions reach these first. 2. With a qwerty keyboard, they are very nice to use. Yep, iPhone screen keys beat Android screen keys hands down, so qwerty is a great boon. There are newer models with qwerty but none as inexpensive and as well "hacker-supported". 3. The biggest downside, battery time, is gone if you buy the bigger battery. And currently most of these phones are sold due to their battery being about to die. 4. The CPU speed while inferior to newest models, is still fine, and the cost is way lower. 5. The only peripherial sometimes found in other models is camera flash. Everything else is there. 6. Used = no contract, or extra bonuses within current contract for extending without acquiring a new phone.
Of course the first thing to do is to root and upgrade to Android 2.2 and get the overclock widget, since the phone has been purposely downclocked by the manufacturer to extend the battery life. This way you get an acceptable performance (vs quite a sucky one of the original) and the extended battery is completely capable of handling the extra load.
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
the last page of the manual contains the sacred phrase: "This device uses software and libraries licensed under GNU GPL, GNU LGPL and Apache licenses. According to requirements of these licenses, our company will make source code of this software available to all interested customers. In order to obtain the source code, please contact [email]"
Must make it available ON REQUEST, to a person who received the binary. Not ship with the tablet. Not publish on the website. Not mail it to anyone who asks, ever.
If I have purchased the tablet, I am entitled to request the sources from the distributor. And they must make them available to me them in reasonable amount of time.
I did study this bit for a while. We're making a big embedded industrial product that runs on Linux. We don't even have the sources in any form that could be shipped - the repository is a mix of Free and proprietary. But the last page of the manual contains the sacred phrase: "This device uses software and libraries licensed under GNU GPL, GNU LGPL and Apache licenses. According to requirements of these licenses, our company will make source code of this software available to all interested customers. In order to obtain the source code, please contact [email]"
We're pretty well aware where the line goes - what is our modifications of the OS which virally became GPL), which is userspace (proprietary) and which is glue logic to LGPL libraries (and has to be made available). If one of our customers requests the sources, we will have to extract the free ones from the repository, attach the toolchain, pack it up and send. But since our customers are not in the IT industry, and essentially want the devices to sit and do their job without ever being touched, we have a reasonable belief we will never have to act upon this requirement.
And no, we are not under obligation to give our sources to random hackers who did not purchase our specialized $15k piece of equipment (with the firmware) first.
I think you ought to discuss it with my boss. The deadlines rarely allow time for writing test units. Unfortunately much more customers value rapid delivery and active support afterwards than spending more time waiting for a more polished product, and as the case is, the company that has its product released first wins - and bugs can be fixed later.
Sure I'm not happy about it but that's the reality out there.
You are horribly wrong. You're so wrong it is mind-boggling.
Interpreted code can still be parsed a'priori for syntactic validity. This won't be 100% sure (for stuff like 'eval string') but WAY better than nothing.
An aggressively picky compiler will catch 90% errors leaving the programmer with 10% as much work debugging, and the resulting production code with 90% less remaining (unnoticed) bugs overall.
The absolute responsibility of a compiler/interpreter/VM is to minimize chances of human error. Ignoring machine-detectable errors "because the programmer shouldn't have made them in the first place" is a faulty, evil design. Errors happen, will happen, and the language, IDE, compiler, automated tests, QA procedures and about every tool at programmer's disposal is intended to make detecting them easier. The wishful thinking "be a good programmer and just don't make errors, and it's not the system's job to ensure you were correct" is at fault of some of major disasters. Including at least one NASA probe crash.
Of course you can't depend on the compiler to solve all your problems and find all your bugs. But every procedure can fail. Every test can miss out things. A test can be faulty too. You ought to receive any and every suggestion of error from every source possible. You will not catch all bugs, never. But by consciously suppressing warnings from some source, you just increase the number of bugs shipped.
Also, in this thing you might have heard of, known as The Real World, there's this odd concept called "deadlines". Meaning getting every possible subroutine and condition tested before shipping is often not plausible.
Interestingly, if you're looking for a job at a big business corporation (not IT-focused, just utilizing IT for its miscellaneous other goals) you'll find knowing BASIC (VB.net) does you much more good than knowing Python.
You seem to have missed the essential phrase run-time.
I have no beef against Python using whitespaces. But I'd rather be warned I made a typo in an obscure procedure called once a year when I first start the program, not when it encounters that procedure after a year.
And even then the common practice was to label lines in increments of 10, so if you wanted to put something between your 10 print "hello" and 20 goto 10, you could just write 15 print "world" and renum only if you needed to insert more than 10 lines (and couldn't use gosub for some weird-ass reason).
For now it's good-to-neutral, magnetic north becoming actual north. But it may become rapidly unpleasant if it continues. Due to layout of magnetic lines, the magnetosphere doesn't protect the magnetic poles from solar wind, except the unprotected "pits" are perpendicular to it, so no harm done. But if the magnetic poles move closer to the tropics, aiming towards the Sun, some inhabited areas can become dangerously exposed to cosmic rays.
Natural or not, it would definitely mean trouble for these areas, and there's very little we could do about it.
"And yes, mankind has lived thru reversals entirely unaware." Only if you really stretch the definition of mankind.
The last reversal occured 780,000 years ago. Homo heidelbergensis, the direct ancestor of both Homo neanderthalensis and Homo sapiens lived about 600,000 years ago. If you're willing to call the pre-Neanderthal population of genus Homo the "mankind", then yes, it lived through the reversals.
So? Don't hack it now so that you could hack it later? But don't hack it later so that you could hack it even later?
If we don't hack it, there's no practical difference whether it's locked out or not.
Besides, how many cards was that tested on? How reliably can the hack be replicated across different batches of cards?
Thing is, often the "disabled" part is one that didn't pass tests. So, they get 60% yield of the chip with all the features, the remaining 40% have the extra parts faulty. But the market demands a 40% more expensive - 60% less expensive production split, so on top of the batch of 40% with faulty, disabled features, 20% of production that is all good gets this part disabled. So, you have 1/3 chance the card you bought can be "unlocked" and run the extra stuff, and 2 in 3 cheaper cards will overhear, throw random errors or not run at all with the extra parts enabled.
Some write block diagrams. Some juggle massive structures in their memory. Some write essential pieces on paper. Some try UML.
I personally find plain, well-commented top-level code to be most readable. My project is actual code, not quite functional because it calls many lower-level functions that are yet to be written, and likely to undergo a few iterations before it reaches final shape - as any plan does, but trying to resemble the final code as closely as possible and iteratively, getting there. There are advantages and disadvantages. The primary disadvantages are that it's not as readable to laymen, but I can still write a nice documentation for them. The advantages are that if the programming language makes a certain feature difficult or impossible, it is immediately apparent and can be fixed at once, instead of trying to implement unrealistic plan assumptions into code once the plan is made final. And also saving time writing the final code.
Still, at my 4-finger-combo, I can type moderately fast while creating correct code. I've seen kids who could touch-type faster than me, but didn't even know what programming is all about.
Actually, the more you type and the less you pause to think the more likely what you type will have to be scrapped later. I can do something as 15 loops one under another. Or I can find a pattern in what these loops are similar to each other and write the code as two nested loops. Surely fast typing would make writing the 15 loops easier...
I've got to agree with the other guy. The apparent sleekness of bikers may be misguiding. It looks like a biker turns on a dime, and yes, once the turn starts, it's pretty narrow. But if a biker turns the handle bar like a car driver, he'll just fall. Rapid braking, sharp turning, this all requires preparation - shift your body weight, turn minimally to the other side, let the bike dip towards the curve a little, move your weight backwards. The sharp turn at high speed itself takes 2-3s but the biker took another 2-3s to prepare for it. I have very good brakes in my bike but if I use them, I'll fall over the handle bars, hitting the road face first. So I have to brake the hind brake lightly, shifting my weight, bracing myself, and only then I can depress front brake fully, and go to a standstill from a rather high speed in a matter of 5-10 meters... after starting braking good 20 meters earlier.
Unexpected rapid turn is very difficult to execute. You don't get a dip deep enough so your turning radius won't be short enough... and you slam whatever obstacle appeared. Add some slippery surface where the bike will skid, which is very nice when you're about to stop but very dangerous if your speed is still too high (and totally kills any ability to turn controllably) and you have a crash ready.
I guess it all depends on trains and tracks. Here, in Poland, you hear the train a good minute before it passes by. "Silent rails" exist, but are expensive and require well-maintained "fleet" to survive - if you hear one-two cars literally jumping with each turn of the wheels the whole empty metal box resonating, meaning likely the bearings of the axis damaged, you can hear them from faaaar away. The rails squeak loudly. The engine whinies quite a bit. Nope, not nearly quiet enough.
There is a case where you can get hit by a train easily though. A single engine, or one pulling 2-3 cars, on a side track, appearing from behind some trees, going quite slowly, drowned out by cars. I remember seeing one maybe 10 meters from me, startling me totally.
Hopefuly, that if you put a 50GB Truecrypt file-partition in your dropbox, it doesn't send all 50GB to the server if you changed one file in your truecrypt virtual drive.
Slashdot Mirror
I'm pretty sure EU consumer protection laws disallow this kind of practices. Yes, they can change what they like. No, I don't have to agree, which leads to termination of contract with no additional fees.
Get a used HTC Dream aka Google G1. Plus "extended battery".
1. They are on the market the longest, making their "hacker" support the most complete. Yes, they are alive and popular, new Cyanogen versions reach these first.
2. With a qwerty keyboard, they are very nice to use. Yep, iPhone screen keys beat Android screen keys hands down, so qwerty is a great boon. There are newer models with qwerty but none as inexpensive and as well "hacker-supported".
3. The biggest downside, battery time, is gone if you buy the bigger battery. And currently most of these phones are sold due to their battery being about to die.
4. The CPU speed while inferior to newest models, is still fine, and the cost is way lower.
5. The only peripherial sometimes found in other models is camera flash. Everything else is there.
6. Used = no contract, or extra bonuses within current contract for extending without acquiring a new phone.
Of course the first thing to do is to root and upgrade to Android 2.2 and get the overclock widget, since the phone has been purposely downclocked by the manufacturer to extend the battery life. This way you get an acceptable performance (vs quite a sucky one of the original) and the extended battery is completely capable of handling the extra load.
That is the reason for these ships from being armed.
Not being a native English speaker, I have a question: is this a valid English form of negation?
Only where the server is located.
After all, protesters arriving from other countries to a protest don't need separate licenses.
Did I miss anything?
Must make it available ON REQUEST, to a person who received the binary.
Not ship with the tablet. Not publish on the website. Not mail it to anyone who asks, ever.
If I have purchased the tablet, I am entitled to request the sources from the distributor. And they must make them available to me them in reasonable amount of time.
I did study this bit for a while. We're making a big embedded industrial product that runs on Linux. We don't even have the sources in any form that could be shipped - the repository is a mix of Free and proprietary. But the last page of the manual contains the sacred phrase: "This device uses software and libraries licensed under GNU GPL, GNU LGPL and Apache licenses. According to requirements of these licenses, our company will make source code of this software available to all interested customers. In order to obtain the source code, please contact [email]"
We're pretty well aware where the line goes - what is our modifications of the OS which virally became GPL), which is userspace (proprietary) and which is glue logic to LGPL libraries (and has to be made available). If one of our customers requests the sources, we will have to extract the free ones from the repository, attach the toolchain, pack it up and send. But since our customers are not in the IT industry, and essentially want the devices to sit and do their job without ever being touched, we have a reasonable belief we will never have to act upon this requirement.
And no, we are not under obligation to give our sources to random hackers who did not purchase our specialized $15k piece of equipment (with the firmware) first.
I think you ought to discuss it with my boss. The deadlines rarely allow time for writing test units. Unfortunately much more customers value rapid delivery and active support afterwards than spending more time waiting for a more polished product, and as the case is, the company that has its product released first wins - and bugs can be fixed later.
Sure I'm not happy about it but that's the reality out there.
You are horribly wrong. You're so wrong it is mind-boggling.
Interpreted code can still be parsed a'priori for syntactic validity. This won't be 100% sure (for stuff like 'eval string') but WAY better than nothing.
An aggressively picky compiler will catch 90% errors leaving the programmer with 10% as much work debugging, and the resulting production code with 90% less remaining (unnoticed) bugs overall.
The absolute responsibility of a compiler/interpreter/VM is to minimize chances of human error. Ignoring machine-detectable errors "because the programmer shouldn't have made them in the first place" is a faulty, evil design. Errors happen, will happen, and the language, IDE, compiler, automated tests, QA procedures and about every tool at programmer's disposal is intended to make detecting them easier. The wishful thinking "be a good programmer and just don't make errors, and it's not the system's job to ensure you were correct" is at fault of some of major disasters. Including at least one NASA probe crash.
Of course you can't depend on the compiler to solve all your problems and find all your bugs. But every procedure can fail. Every test can miss out things. A test can be faulty too. You ought to receive any and every suggestion of error from every source possible. You will not catch all bugs, never. But by consciously suppressing warnings from some source, you just increase the number of bugs shipped.
Also, in this thing you might have heard of, known as The Real World, there's this odd concept called "deadlines". Meaning getting every possible subroutine and condition tested before shipping is often not plausible.
Actually, programming for fun can vastly improve your ability to learn maths, and the unforgiving syntax teaches diligence in correct spelling.
Many years before I learned the circle equation and trigonometry at school, I was already drawing sines, circles and Lissajous shapes on Atari.
Interestingly, if you're looking for a job at a big business corporation (not IT-focused, just utilizing IT for its miscellaneous other goals) you'll find knowing BASIC (VB.net) does you much more good than knowing Python.
10 gosub 10
the first time I found out 64KB is NOT enough for everyone.
You seem to have missed the essential phrase run-time.
I have no beef against Python using whitespaces. But I'd rather be warned I made a typo in an obscure procedure called once a year when I first start the program, not when it encounters that procedure after a year.
And even then the common practice was to label lines in increments of 10, so if you wanted to put something between your 10 print "hello" and 20 goto 10, you could just write 15 print "world" and renum only if you needed to insert more than 10 lines (and couldn't use gosub for some weird-ass reason).
Do not worry, the £6mln was fully covered by traffic violation tickets paid by the remaining 2,480 caught.
Recently they started using CCTV to hand out parking tickets. A MASSIVE campaign of that.
I wonder how many of these "crimes" were "illegal parking".
As for protection against cosmic radiation and solar wind, yes, they did.
For now it's good-to-neutral, magnetic north becoming actual north.
But it may become rapidly unpleasant if it continues. Due to layout of magnetic lines, the magnetosphere doesn't protect the magnetic poles from solar wind, except the unprotected "pits" are perpendicular to it, so no harm done. But if the magnetic poles move closer to the tropics, aiming towards the Sun, some inhabited areas can become dangerously exposed to cosmic rays.
Natural or not, it would definitely mean trouble for these areas, and there's very little we could do about it.
"And yes, mankind has lived thru reversals entirely unaware." Only if you really stretch the definition of mankind.
The last reversal occured 780,000 years ago.
Homo heidelbergensis, the direct ancestor of both Homo neanderthalensis and Homo sapiens lived about 600,000 years ago.
If you're willing to call the pre-Neanderthal population of genus Homo the "mankind", then yes, it lived through the reversals.
So?
Don't hack it now so that you could hack it later? But don't hack it later so that you could hack it even later?
If we don't hack it, there's no practical difference whether it's locked out or not.
Besides, how many cards was that tested on? How reliably can the hack be replicated across different batches of cards?
Thing is, often the "disabled" part is one that didn't pass tests. So, they get 60% yield of the chip with all the features, the remaining 40% have the extra parts faulty. But the market demands a 40% more expensive - 60% less expensive production split, so on top of the batch of 40% with faulty, disabled features, 20% of production that is all good gets this part disabled. So, you have 1/3 chance the card you bought can be "unlocked" and run the extra stuff, and 2 in 3 cheaper cards will overhear, throw random errors or not run at all with the extra parts enabled.
Depends on how you like to plan.
Some write block diagrams.
Some juggle massive structures in their memory.
Some write essential pieces on paper.
Some try UML.
I personally find plain, well-commented top-level code to be most readable. My project is actual code, not quite functional because it calls many lower-level functions that are yet to be written, and likely to undergo a few iterations before it reaches final shape - as any plan does, but trying to resemble the final code as closely as possible and iteratively, getting there. There are advantages and disadvantages. The primary disadvantages are that it's not as readable to laymen, but I can still write a nice documentation for them. The advantages are that if the programming language makes a certain feature difficult or impossible, it is immediately apparent and can be fixed at once, instead of trying to implement unrealistic plan assumptions into code once the plan is made final. And also saving time writing the final code.
Still, at my 4-finger-combo, I can type moderately fast while creating correct code. I've seen kids who could touch-type faster than me, but didn't even know what programming is all about.
Actually, the more you type and the less you pause to think the more likely what you type will have to be scrapped later.
I can do something as 15 loops one under another. Or I can find a pattern in what these loops are similar to each other and write the code as two nested loops. Surely fast typing would make writing the 15 loops easier...
I've got to agree with the other guy. The apparent sleekness of bikers may be misguiding. It looks like a biker turns on a dime, and yes, once the turn starts, it's pretty narrow. But if a biker turns the handle bar like a car driver, he'll just fall. Rapid braking, sharp turning, this all requires preparation - shift your body weight, turn minimally to the other side, let the bike dip towards the curve a little, move your weight backwards. The sharp turn at high speed itself takes 2-3s but the biker took another 2-3s to prepare for it. I have very good brakes in my bike but if I use them, I'll fall over the handle bars, hitting the road face first. So I have to brake the hind brake lightly, shifting my weight, bracing myself, and only then I can depress front brake fully, and go to a standstill from a rather high speed in a matter of 5-10 meters... after starting braking good 20 meters earlier.
Unexpected rapid turn is very difficult to execute. You don't get a dip deep enough so your turning radius won't be short enough... and you slam whatever obstacle appeared. Add some slippery surface where the bike will skid, which is very nice when you're about to stop but very dangerous if your speed is still too high (and totally kills any ability to turn controllably) and you have a crash ready.
I guess it all depends on trains and tracks. Here, in Poland, you hear the train a good minute before it passes by. "Silent rails" exist, but are expensive and require well-maintained "fleet" to survive - if you hear one-two cars literally jumping with each turn of the wheels the whole empty metal box resonating, meaning likely the bearings of the axis damaged, you can hear them from faaaar away. The rails squeak loudly. The engine whinies quite a bit. Nope, not nearly quiet enough.
There is a case where you can get hit by a train easily though. A single engine, or one pulling 2-3 cars, on a side track, appearing from behind some trees, going quite slowly, drowned out by cars. I remember seeing one maybe 10 meters from me, startling me totally.
Hopefuly, that if you put a 50GB Truecrypt file-partition in your dropbox, it doesn't send all 50GB to the server if you changed one file in your truecrypt virtual drive.