You're not supposed to make your own apps. Apple isn't marketing to people who want to make their own apps. They're marketing to people who like the idea of an Apple store full of great apps (which run only on Apple's hardware). Those people then go out and buy Apple hardware so that they can have access to this great store.
It costs $99 per year to make apps that will only run on Apple's hardware, and if it costs $99 per year, people who'd otherwise make crappy apps that nobody wants will be dissuaded from doing so, improving the overall quality of the Apple store's apps.
Net result: Apple store contains lots of great apps which run only on Apple's hardware, and fewer lemons.
This presumes one is so fortunate as to have ready access to a river upstream from where others are dumping their wastes, or to have on hand (or materials to build) a cistern, and further presumes sufficient flow or rainfall.
No, it presumes that you'd probably have to run it through a coffee filter (or let it settle) and boil it or add a disinfectant such as bleach or iodine in order to use the free "unlimited water". (obligatory "kids these days"...)
Or you could buy your municipality's tap water and have it be "drinkable in a pinch" without any of that.
What else should they do, shine your shoes? If you can't really imagine what they could do to earn anything above a 5 or 6, your scale effectively just goes to 5 or 6, so re-scale it to 10 for the purposes of their survey. Or make it go to eleven, hell if I care.
Hehehe, no, you are confusing "sanitary engineer" with "sanitation engineer" (in fact, Wikipedia puts "Not to be confused with..." on both with respect to the other).
A sanitary engineer might design a trash truck, but sanitation engineer is a fancy name for the guy who drives it (or rides on the back). He's an "engineer" in the same sense that the engineer on a train is.
Oh, and I should mention... optical signals only have 1 lead (fiber), not 2. My brain is too tired to try to figure out what that would mean as far as trying to use optical diodes to accomplish anything similar to the current-direction-based logic used for that multiplier.
That's a pretty interesting concept, but it uses an entirely different binary representation (current polarity switch for 0/1, rather than voltage potential). In essence, it means that every signal is 2 leads rather than 1, and switching them creates a NOT gate.
You might be right, but I'd want to see a working flip-flop before I'd accept that diodes could be used for digital logic.
You can't build logic for any given truth table using nothing but diodes. You can only build logic for some truth tables, which doesn't give you programmable digital logic. Happy now?
Your point being, I take it, that you can create certain gates with diodes (AND and OR).
There are some truth tables which can be achieved by nothing but AND and OR. There are some that cannot. All truth tables can be achieved by solely the use of either NAND or NOR, but you can't create those gates using just diodes.
Digital logic requires the ability to do something on the 0 state. Without an inverting gate, you can't do that, and diodes can't invert.
Not all logical functions can be implemented in diode logic alone; only the non-inverting logical AND and logical OR functions can be realized by diode gates.
You can build some logic using a plain old switch, too: IF the switch is closed, THEN light the bulb. Not terribly useful. Neither is diode logic.
My point was that the signal is the important part. They have no way of switching this optical diode.
The diode effect is fairly irrelevant and unimportant. As a matter of fact, digital logic doesn't require something to act like diode at all: relay logic doesn't use diodes.
The "most fundamental part" of logic isn't one-way transmission, it's the ability to control that transmission by applying a voltage to the transistor's gate. The fact that current will only flow one direction between the emitter and the collector is really not that important by comparison.
Yes, but all of the I/O has to go through the DOM, which is awkward and event-driven. Basically, it requires you to create an I/O library if you want to do anything more complex than prompt() and alert().
For a while I was working on a project which I intended to eventually be a BASIC-in-browser, kind of similar to the Club Compy project... but once I got the basic I/O libraries written (it uses a canvas with named-similarly-to-BASIC Javascript functions to do things like print, locate, and change colors), I got kind of tired of working on it when I realized that it'd probably make a lot more sense to just do everything in Javascript using the I/O engine that I'd built rather than try to make it interpret actual BASIC code.
It was kind of a fun project, though, and it gave me an excuse to delve into things like BASIC's internal storing of floating-point numbers (which for some reason I wanted to reproduce exactly - well, partly because it'd be necessary in order to implement the MKS$ and MKD$ functions anyway). It's not a IEEE standard float, but it's similar.
I'm aware that newer versions of BASIC include those things, but I was under the impression that we were specifically talking about the old original versions that didn't, since those were all TFS had mentioned.
It's not clear that we're talking about those newer versions of BASIC. As far as I knew, we were talking about the original ones that did, in fact, not have any usable stacks or variable scoping.
It's not like the DOS versions of BASIC I used to play around with were very powerful (unless the POKE command counts).
I made some pretty cool BASIC programs after I found some code that wrapped an INT 33h call in an assembly-language subroutine to read the position of the mouse and determine if a button was pressed. (The built-in commands to read the light pen position only worked when a button on the mouse was pressed, which wasn't too useful.)
Not sure what version of BASIC you're talking about, but the version of BASIC that I was first using didn't even have functions, much less local variables. Every variable had global scope - in fact, they didn't even go away when your program ended. You could use nested GOSUB-RETURN blocks, and BASIC managed a stack for those internally, but you couldn't actually use that stack - i.e. for local variables or parameters to the subroutines.
I'd say that BASIC's real success was that it made it easy for people to do the stuff that they actually wanted to do: string manipulation, graphics-mode, and bleeps and bloops. My initial forages into C were rather discouraging - when I learned how much trouble it was to create and manipulate simple strings, I lost interest in that language quickly, since it was so easy in BASIC. Might as well have been using assembly language as C; there's not much difference. BASIC did all of that stuff for you. Perhaps even worse, none of the books that I had for C even suggested such a thing as a graphics mode, making the computer make sounds, or even rudimentary stuff like relocating the cursor or clearing the screen or even changing the color of text that you printed - basically, everything that made the computer more interesting than a teletype machine.
Any successful beginner-orientated language needs to be similarly helpful when it comes to doing simple stuff that everyone will want to use in their programs - and note that people's expectations for computers have progressed quite a bit beyond 16-color, low-resolution graphics modes and simple bleeps and bloops.
I read that exactly the opposite of the way that you appear to have read it. You read it and thought of the ancient, dead language that was written in the 80s. I read it and thought of the language for ancient, dead computers that was both usable by average people and, more importantly, gave access to most of the functionality that those computers had - slowly - and it wasn't much, but it was there.
To extend on that line of thought, I'd say that Javascript "put BASIC on the web", so to speak. Yes, just about anyone can learn it, and probably pick up all sorts of bad habits - but they're programming, and it gives them access to a growing set of features as browsers get faster and more complicated.
So when I hear the question "why can't we put a BASIC on the phone", to me the question means, why can't we put a language on the phone that people can actually use and which utilizes the phone's capabilities?
LEGO is a registered trademark. LEGO-brand bricks are not "legos", they are LEGO bricks. Non-LEGO-brand bricks are not "legos", they are small plastic non-LEGO toy bricks.
Using "legos" to refer to them just makes you sound like an uneducated fool. The fact that you've been told otherwise and will continue to do so makes you a stubborn fool. Go right ahead, I won't stop you - although if you have any money I'm sure LEGO would love to sue you into oblivion.
No. Perhaps I should try to explain it again, very carefully. See if you can follow this.
If it's hashed on the client side, either it is or it isn't also hashed on the server side. Consider these scenarios separately:
First, assuming it's only hashed once, on the client side. That hash is transmitted and stored on the server. If someone dumps the database and gets those hashes, they don't need the original password: hack the client-side to just send the correct hash without needing the original password to create that hash.
The other scenario, where it's hashed at both the client and the server, implies that you don't trust the website to transmit your un-hashed password - in which case, you shouldn't trust it to have your un-hashed password in the first place. Hash your password first, then use that as a password for that site.
In neither case does automatically hashing the password on the client-side accomplish anything useful. The first is woefully insecure and the second is no more secure than sending the password itself. If you're using SSL, it should be fine.
Slashdot Mirror
Should take about 6 days for the entire internet to catch up - according to this site its TTL is 6 days.
If you use Flash to handle the uploads it'd be trivial to split it into multiple POSTs and recombine on the server-side afterward.
The first post is generally a waste of time. The second post is usually also a waste of time, often someone trying to GET the first post.
Do you have any idea how weird that looks to a pedant like myself?
<form method="post"> => POST the first post
(devil's advocate, here)
You're not supposed to make your own apps. Apple isn't marketing to people who want to make their own apps. They're marketing to people who like the idea of an Apple store full of great apps (which run only on Apple's hardware). Those people then go out and buy Apple hardware so that they can have access to this great store.
It costs $99 per year to make apps that will only run on Apple's hardware, and if it costs $99 per year, people who'd otherwise make crappy apps that nobody wants will be dissuaded from doing so, improving the overall quality of the Apple store's apps.
Net result: Apple store contains lots of great apps which run only on Apple's hardware, and fewer lemons.
This presumes one is so fortunate as to have ready access to a river upstream from where others are dumping their wastes, or to have on hand (or materials to build) a cistern, and further presumes sufficient flow or rainfall.
No, it presumes that you'd probably have to run it through a coffee filter (or let it settle) and boil it or add a disinfectant such as bleach or iodine in order to use the free "unlimited water". (obligatory "kids these days"...)
Or you could buy your municipality's tap water and have it be "drinkable in a pinch" without any of that.
What else should they do, shine your shoes? If you can't really imagine what they could do to earn anything above a 5 or 6, your scale effectively just goes to 5 or 6, so re-scale it to 10 for the purposes of their survey. Or make it go to eleven, hell if I care.
Hehehe, no, you are confusing "sanitary engineer" with "sanitation engineer" (in fact, Wikipedia puts "Not to be confused with..." on both with respect to the other).
A sanitary engineer might design a trash truck, but sanitation engineer is a fancy name for the guy who drives it (or rides on the back). He's an "engineer" in the same sense that the engineer on a train is.
Oh, and I should mention... optical signals only have 1 lead (fiber), not 2. My brain is too tired to try to figure out what that would mean as far as trying to use optical diodes to accomplish anything similar to the current-direction-based logic used for that multiplier.
That's a pretty interesting concept, but it uses an entirely different binary representation (current polarity switch for 0/1, rather than voltage potential). In essence, it means that every signal is 2 leads rather than 1, and switching them creates a NOT gate.
You might be right, but I'd want to see a working flip-flop before I'd accept that diodes could be used for digital logic.
You can't build logic for any given truth table using nothing but diodes. You can only build logic for some truth tables, which doesn't give you programmable digital logic. Happy now?
Your point being, I take it, that you can create certain gates with diodes (AND and OR).
There are some truth tables which can be achieved by nothing but AND and OR. There are some that cannot. All truth tables can be achieved by solely the use of either NAND or NOR, but you can't create those gates using just diodes.
Digital logic requires the ability to do something on the 0 state. Without an inverting gate, you can't do that, and diodes can't invert.
You can build some logic using diodes.
Not all logical functions can be implemented in diode logic alone; only the non-inverting logical AND and logical OR functions can be realized by diode gates.
You can build some logic using a plain old switch, too: IF the switch is closed, THEN light the bulb. Not terribly useful. Neither is diode logic.
My point was that the signal is the important part. They have no way of switching this optical diode.
The diode effect is fairly irrelevant and unimportant. As a matter of fact, digital logic doesn't require something to act like diode at all: relay logic doesn't use diodes.
The "most fundamental part" of logic isn't one-way transmission, it's the ability to control that transmission by applying a voltage to the transistor's gate. The fact that current will only flow one direction between the emitter and the collector is really not that important by comparison.
You can't build logic from diodes.
Yes, but all of the I/O has to go through the DOM, which is awkward and event-driven. Basically, it requires you to create an I/O library if you want to do anything more complex than prompt() and alert().
For a while I was working on a project which I intended to eventually be a BASIC-in-browser, kind of similar to the Club Compy project... but once I got the basic I/O libraries written (it uses a canvas with named-similarly-to-BASIC Javascript functions to do things like print, locate, and change colors), I got kind of tired of working on it when I realized that it'd probably make a lot more sense to just do everything in Javascript using the I/O engine that I'd built rather than try to make it interpret actual BASIC code.
It was kind of a fun project, though, and it gave me an excuse to delve into things like BASIC's internal storing of floating-point numbers (which for some reason I wanted to reproduce exactly - well, partly because it'd be necessary in order to implement the MKS$ and MKD$ functions anyway). It's not a IEEE standard float, but it's similar.
I'm aware that newer versions of BASIC include those things, but I was under the impression that we were specifically talking about the old original versions that didn't, since those were all TFS had mentioned.
It's not clear that we're talking about those newer versions of BASIC. As far as I knew, we were talking about the original ones that did, in fact, not have any usable stacks or variable scoping.
It's not like the DOS versions of BASIC I used to play around with were very powerful (unless the POKE command counts).
I made some pretty cool BASIC programs after I found some code that wrapped an INT 33h call in an assembly-language subroutine to read the position of the mouse and determine if a button was pressed. (The built-in commands to read the light pen position only worked when a button on the mouse was pressed, which wasn't too useful.)
Not sure what version of BASIC you're talking about, but the version of BASIC that I was first using didn't even have functions, much less local variables. Every variable had global scope - in fact, they didn't even go away when your program ended. You could use nested GOSUB-RETURN blocks, and BASIC managed a stack for those internally, but you couldn't actually use that stack - i.e. for local variables or parameters to the subroutines.
I'd say that BASIC's real success was that it made it easy for people to do the stuff that they actually wanted to do: string manipulation, graphics-mode, and bleeps and bloops. My initial forages into C were rather discouraging - when I learned how much trouble it was to create and manipulate simple strings, I lost interest in that language quickly, since it was so easy in BASIC. Might as well have been using assembly language as C; there's not much difference. BASIC did all of that stuff for you. Perhaps even worse, none of the books that I had for C even suggested such a thing as a graphics mode, making the computer make sounds, or even rudimentary stuff like relocating the cursor or clearing the screen or even changing the color of text that you printed - basically, everything that made the computer more interesting than a teletype machine.
Any successful beginner-orientated language needs to be similarly helpful when it comes to doing simple stuff that everyone will want to use in their programs - and note that people's expectations for computers have progressed quite a bit beyond 16-color, low-resolution graphics modes and simple bleeps and bloops.
I read that exactly the opposite of the way that you appear to have read it. You read it and thought of the ancient, dead language that was written in the 80s. I read it and thought of the language for ancient, dead computers that was both usable by average people and, more importantly, gave access to most of the functionality that those computers had - slowly - and it wasn't much, but it was there.
To extend on that line of thought, I'd say that Javascript "put BASIC on the web", so to speak. Yes, just about anyone can learn it, and probably pick up all sorts of bad habits - but they're programming, and it gives them access to a growing set of features as browsers get faster and more complicated.
So when I hear the question "why can't we put a BASIC on the phone", to me the question means, why can't we put a language on the phone that people can actually use and which utilizes the phone's capabilities?
No. It has not. It does not. It is not.
http://tess2.uspto.gov/bin/showfield?f=doc&state=4003:ok1hd4.2.4
LEGO is a registered trademark. LEGO-brand bricks are not "legos", they are LEGO bricks. Non-LEGO-brand bricks are not "legos", they are small plastic non-LEGO toy bricks.
Using "legos" to refer to them just makes you sound like an uneducated fool. The fact that you've been told otherwise and will continue to do so makes you a stubborn fool. Go right ahead, I won't stop you - although if you have any money I'm sure LEGO would love to sue you into oblivion.
No. LEGO is the brand name. They are LEGO bricks. They are not Legos.
1 2 3 4 5 6 7 8 9 0 .
q w e r t y u i o p
a s d f g h j k l ;
z x c v b n m ,
No. Perhaps I should try to explain it again, very carefully. See if you can follow this.
If it's hashed on the client side, either it is or it isn't also hashed on the server side. Consider these scenarios separately:
First, assuming it's only hashed once, on the client side. That hash is transmitted and stored on the server. If someone dumps the database and gets those hashes, they don't need the original password: hack the client-side to just send the correct hash without needing the original password to create that hash.
The other scenario, where it's hashed at both the client and the server, implies that you don't trust the website to transmit your un-hashed password - in which case, you shouldn't trust it to have your un-hashed password in the first place. Hash your password first, then use that as a password for that site.
In neither case does automatically hashing the password on the client-side accomplish anything useful. The first is woefully insecure and the second is no more secure than sending the password itself. If you're using SSL, it should be fine.