``The point is, Microsoft created the technology and then it ended up in other browsers.''
No. They created something based on ActiveX.
Other browsers created a similar feature, which did pretty much exactly the same, but without ActiveX.
The feature that ended up in other browsers was not the same as the one Microsoft invented. The important difference between the two is that Microsoft's depends on Microsoft's proprietary ActiveX technology. This means AJAX is _not_ a non-proprietary innovation from Microsoft. What Microsoft came up with was proprietary. What ended up in other browsers was a knock-off with the proprietary lock-in parts replaced.
AJAX is not a case of Microsoft coming up with something that went on to become a standard. It's a case of Microsoft trying to lock people into their proprietary platform, and failing. The features were duplicated by the competition, and libraries were written that work with both Microsoft's and the rest of the world's implementation.
Now, there are actually examples of Microsoft creating standards. And I mean standards that don't lock you into their platform. AJAX is just not one of them.
(I hope this is going to be formatted correctly. It looks ok in w3m...)
Confidentiality
Only the intended recipient is able to read the message. No government spying.
Use public key cryptography. Encrypt the message with the public key of the recipient. Only the holder of the corresponding private key can decrypt the message.
Integrity
The message you send is the message they receive. No monkeying in the middle.
Use message authentication codes. Encrypt a digest of the message with the sender's private key. Verifying the authentication code proves that the message has been sent by the purported sender and has not been tampered with.
Authenticity
The message will say it's from Alice if and only if it was sent by Alice. No spoofed From: lines.
See previous solution.
Roaming Access
Access your messages from anywhere. No fragmentation over several systems.
Allow users to keep messages on the server. Store the user's keys on key servers. Encrypt the private key, so that only an authenticated user can use it.
8-bit Cleanliness
All 256 byte values should be allowed. No more base64.
Reputation System
Senders, servers, and recipients have reputations. Messages may receive special treatment based on the reputation of their sources.
Users should be able to choose among various reputation services, so that various methods for establishing reputations can be tried.
----
Protocol
- Textual
- Layered on TLS
- Server and client are authenticated using keys
- Sending message:
* Fetch recipient key
* Specify destination
- Server contacts destination server
- Server verifies destination account
- Server acknowledges destination
* Send headers (pubkey encrypted)
- Server forwards headers to destination
- Server acknowledges headers
* Send body (symmetrically encrypted)
- Server saves body
- Server acknowledges message
- Receiving message:
* Fetch headers
* Decrypt headers
* Send headers to reputation server
- Reputation server acknowledges headers
* Request body
- Server contacts sending server
- Server fetches body
- Server sends body
* Decrypt body
* If message is spam, report to reputation server
I have thought about this matter, and I think it is important to factor in how much data is an acceptable loss.
My/home is backed up every night, and backups are kept for 12 months. That means there are three ways I can lose data:
1. I lose it before it's been backed up. This applies to, at most, the last 24 hours of work I do. 2. I lose data after it's been backed up, and I don't notice for at least 12 months. 3. The data disappears from both the live system and the backup, before I can recover it.
2 is fairly unlikely. 3 is one that worries me, but I'm working on that by arranging my backup to be duplicated off-site. 1 is the one that bothers me the most. I imagine my harddisk failing on the day I just finished a large project, thus replacing the joy of having finished it by the pain of just having lost the final pieces.
What TFA talks about (losing data before it has been written to disk) doesn't worry me so much. I doubt I'd lose more than a few minutes of work that way. And I'd know that something had failed, so I would expect the data loss.
It gets more worrisome when you provide services to remote users. Imagine that you run an e-commerce website, and a customer has just placed an order and received a confirmation, and then your machine goes *poof* before the order has been comitted to stable storage. The customer would not be pleased, especially if they had already paid for the order.
I think, in cases like the e-commerce example above, you would want to make sure that changes had been recorded before telling anyone that they had. And now comes a question: is there any way I, as a programmer, can verify that something has been written to stable storage? Can I tell the system (library/operating system/database/whatever) "write this down and don't return to me before you've actually written it"? And preferably without writing _everything_ to stable storage.
For those who want to know what TFA says without actually reading it, it boils down to:
1. What you think you have saved and what has actually been written to stable storage may not be the same. In particular, things may still sit in DRAM, waiting to be written to disk.
2. What gets written to stable storage after the power failure may not be what was intended to be written. You could end up with corrupt data.
3. That's the hardware side of the story; software introduces many more hazards by lengthening the path between your actions and stable storage.
For some reason, I first thought that this would be a competitor to the Eee and its ilk. A Freescale CPU in a netbook sounds like it could be good for battery life, although I wonder how much you can still save by putting in a more efficient CPU, really.
Then I realized this isn't like a netbook at all. It's more like what I think used to be called a "net PC", where you get, basically, a terminal that connects you to the Internet. This means that the real cost of using the computer is $250 plus the cost of extra devices you need, such as a monitor and a keyboard, plus Internet access, plus computation and storage.
I don't think this will fly. You can probably actually save money by buying a netbook, which comes with its own monitor, keyboard, and storage, and thus works with or without Internet access. You would also have your own data near you, instead of under the control of a company that may or may not charge you for it, may or may not provide you access to it tomorrow, and may or may not transfer it to others.
Not that I think the model where you have a dumb terminal and computation and storage happens elsewhere doesn't have its uses. Actually, I think thin clients are a really good idea. But a thin client shouldn't cost as much as $ 250 without monitor and keyboard, and I'm not convinced the world is ready for the computation servers to be on the Internet, not until we can establish more trust in service providers.
The case of the dutch public transport card has all the indications of nobody actually caring about the things most would consider good. There's been shoddy engineering from the beginning, that's why the system still isn't operational nationwide. The project is also ridiculously overspent, eating into taxpayers' money. If the contractor can't deliver for the price they mentioned, it should be their loss, not everyone else's. Security problems have been apparent for a long time, even though this is denied, ignored, and covered up. One positive effect of this is that the cards were found to contain far more personal information than necessary, allowed, and desirable. So, out of all the things they could have spent their resources on, they apparently chose tracking travelers and otherwise invading their privacy. On top of all that, I am not surprised at all that they would try to silence yet another couple of critics.
Really, this isn't about delivering a good product. I don't know what it _is_ about, but I do know it ends up spending tax payers' money on something that isn't good for them, especially if they travel by public transport. I'd very much like to see this investigated. Even if there wasn't any malicious intent, a lot of harm has been done. We need to know what happened, who ordered it to happen, and who allowed it to happen, because I don't want this to happen again. Sadly, I fear I won't get any sizeable part of the Dutch population to support such an investigation, let alone the government, which seems to have "no investigation into possible mistakes" their credo.
``Were I in their situation I would have publically released information on the hack the moment the injunction was overturned. If vendors of ANY type of system want to fuck with people who show every intention of trying to HELP them, they deserve everything they get.''
Yes. But it's not they who get screwed over the most. It's the users of the system, those who paid for the system, and those who get caught abusing the holes.
In some parts of the world (notably the EU), PayPal is, indeed, regulated. Among other things, that means they can't simply lock your account at will. It's an interesting question why the same hasn't been done in the USA. And, actually, whether that's a Good Thing or a Bad Thing.
Isn't the fact that phosphorus stimulates algae growth, which suffocates other lifeforms, common knowledge? I seem to recall being taught this in school...
When I learned to program (I was 8), it was DOS and text mode and BASIC. The programs I wrote were simple "enter some text or numbers, get some response". It doesn't have to have fancy graphics and the like to be interesting.
And I'm not saying that because I'm an old fart. Everybody I know who programs started that way, although the younger folk usually started with GNU or BSD and Perl or Python, rather than DOS and BASIC. They do stuff that looks pretty uninteresting to non-programmers, but is very valuable to them. Usually, they start by automating something that they do often. Sometimes, they've found something they found cool (e.g. a script found on the web) and started tinkering with it. I had a book from the library with source code for a couple of simple games.
Another approach that can be very rewarding is web development. You can get impressive-looking results relatively quickly, and it scales all the way up to what the big guys are doing.
In the end, though, I think programming is something you have to want to learn. You may want your son to learn to program, and your son may be dreaming of making his own great game or operating system, but that's not enough. You need to develop the way of thinking that allows you to break down your idea into what you can express in your programming language, and that takes time and effort. It's going to be frustrating until you get it. Most people aren't really motivated to work through that, and will give up after a short while. That's ok. You can still learn to program when you are older, and you can be happy in life even if you don't ever learn to program at all.
Before the ad-supported Opera, however, people just used the evaluation version.
Money was never what stopped Opera's adoption.
What did stop its adoption is an interesting question, though. It has been a great browser for as long as I can remember - which I think goes back to version 3.something. I used it to test my websites, because Opera was much more picky and standards-compliant than the others. I also used it for my own browsing, because Opera was faster and offered a slew of useful features that other browsers lacked (tons of keyboard shortcuts and tabs being the main ones). Yet, I have never seen Opera at far above 1% in global browser market share stats.
Part of it is undoubtedly inertia. A lot of people will just use what comes with their system, which is probably some version of Internet Explorer or Safari, and perhaps Firefox (and, back in the day, Netscape). Part of it may also be explained by the multitude of websites that have been broken in ways that made them not work with Opera. If you use a lot of such websites, having to switch browsers constantly quickly gets old.
Myself, I stopped using Opera because of stability issues on Linux. Those might have been resolved now, but, nowadays, I run only open-source software on my main system. I am not about to make an exception for Opera; I am satisfied with Konqueror.
I disagree. I think agile development (not web 2.0 - whatever that is) is really a useful methodology. Rather than developing the product for an extensive period of time and finally confronting the customer with what you've cooked up, you periodically show them what you've made and let them provide input on future directions. As a customer, I would like that. I can see progress is being made, and I can spot early if things are going in a direction I don't like.
On the other hand, I have come to appreciate the waterfall model as well. It's good when you know in advance what you want, and it makes it easy to assign different people to work on different parts of the system. When done right, I think it can save a lot of overhead compared to agile development, and you know what you will finally end up with. As a customer, I would value that, because I can go about my business while the software is being developed by others. I'd still want to check on them once in a while, though; something that most customers I've dealt with actually don't seem to do.
So I think both models have their strength. Waterfall is good if you know or can determine in advance what you want built. You analyze the requirements, design the beast, and implement it, and if the specification was good and the devs and testers did their job, you'll have a product that does exactly what you ordered. Agile is good if you don't exactly know what you want. It fits an evironment where there is lots of innovation or competing products - you'll want to add features as you go, in response to changing ideas of what you think will drive customers to you. Waterfall is awful for that, because your product will be outdated by the time it is finished. On the other hand, agile doesn't give you much of an indication of what you will eventually end up with and what it will cost you.
I am so happy I found Debian. Upgrade your whole system with a single command. And if you run stable, you don't even get newer versions of software - you just get (backported) security fixes. Once it works, it just keeps working. It's almost a pity that a certain release will only be supported for a number of years...
``No, we can even measure how surface gravity varies from g=9.78 m/s2 to g=9.82 m/s2 when moving from the equator towards a pole. And this is because Earth is not perfectly round, the people at higher latitudes are closer to the center of Earth and fall faster.''
I've always thought it was a bad idea to include Real World phenomena in your SciFi universe, unless you know how said Real World phenomena work. At least, I find it very annoying when an author describes something in a certain way, and I know it doesn't work that way. It causes the suspension of disbelief to fail, which takes you out of the story, and you'll find yourself staring at a bunch of letters. Kind of like a BSOD shatters the illusion of having windows with documents in them.
``That code is *not* easier to understand. I glanced at your post and thought "first bitwise XOR second"''
I understand where you are coming from, but really, what you're saying is a red herring. Had you known OCaml, it would have been immediately obvious to you what the code did. I considered for a while to use some hypothetical OCamll string concatenation function to prevent people from getting confused like you did, but, in the end, decided against it, because, in OCaml, you would just use the ^ operator. Anyway, as I said in my previous post, the fact that OCaml has an operator for string concatenation is besides the point.
The point is that the way OCaml handles strings allows string concatenation to be expressed succinctly and clearly, whereas, in C, one has to jump through hoops to get it right. This is where the programming language has an influence on the readability of the code. No matter how hard you complain about ^ not being the right symbol for string concatenation, the fact stands that in C, it cannot be expressed that clearly. You need some boilerplate code to do memory managment and check that you are actually passed strings and not NULLs. So, even if you know C, you will have to look at a couple of lines of code, until you figure out that what it actually means is "concatenate the strings first and second".
If it makes it easier for you to understand, feel free to imagine a hypothetical "strcat" function in OCaml, or an hypothetical language that is exactly like OCaml but uses whatever operator you prefer for string concatenation.
In a way, the languages, tools, and libraries prescribed (if any), also constitute a sort of coding practice, in the sense that they impose limits on how you can structure your code.
- The language you work with gives you certain language constructs. These constructs vary per language, and determine how you must express things and what abstractions are available to you. This has a huge impact on the structure of your code.
- Most tools like to structure and format your code a certain way, particularly when the tool generates the code. This is usually a great boon, because it will make it easy for programmers to adhere to the same coding standard and hard for them to deviate. Of course, if what you want is not what the tool wants, the tool starts getting in the way.
- The libraries you work with determine the APIs available to you. This also has a strong influence on the structure of your code. It also interacts with the language constructs available to you, as they may or may not make it easy to build an API you like to work with on top of the API that a library exposes.
Abstraction is particularly important. If a language offers powerful enough abstractions, you can structure your program so that it is easy for humans to understand what it does, and have the compiler translate it to whatever the libraries make available to you. Better abstractions also make your code more reusable.
As an example, in C, strings are character arrays. Arrays in C don't have a size associated with them. The end of a string is indicated by a character with value 0. Furthermore, the type of an array of characters is actually the same as a pointer to a character. C also doesn't have automatic memory management. Suppose now that you wanted to concatenate two strings. There are various ways to do so, but the most obvious one is the strcat function:
char *strcat(char *dest, const char *src)
This function appends src to dest and returns dest (a pointer to the concatenated string).
That is, provided there was actually enough space in dest to hold the combined contents of dest and src, and the terminating NUL. If there wasn't, the function overwrites whatever came after dest, which will usually lead to your program crashing or executing code supplied by a cracker attacking your program.
The correct way to use strcat, then, is something like:
/* The first string, the second string, and a to-be-allocated string for their concatenation. */ char *first, *second, *result;
/* Don't forget to add 1 for the terminating NUL character. */ result = (char*) malloc(strlen(first) + strlen(second) + 1);
/* Copy the contents of first to result. */ strcpy(result, first);
/* Append the contents of second. */ strcat(result, second);
But wait! That's not all! Since the type of an array is actually a pointer, and pointers are allowed to be NULL in C, first and second in the above could actually be NULL. If either one of them is, the program will crash. So we need to add extra code to check for that...
All those many things to remember to concatenate two strings. It doesn't have to be that way. In OCaml, for example, a string is a string, not a pointer to a character, and never null. You don't have to worry about allocating a large enough block of memory, because memory will be allocated as needed, and reclaimed when no longer reachable. As it happens, OCaml also has an operator that concatenates strings. That is besides the point here, but I had to tell you that to explain what the code looks like in OCaml. Namely:
first ^ second
Not only is it much shorter than the C code, it's also easier to understand what it does, and more robust.
I think this sort of thing matters a lot more than how you format or indent your code, and pretty much everything else that normally falls under the nomer of "coding standards".
Some ISPs will indeed show their annoying search pages even if the domain exists. I used to access the Internet via my phone and get redirected to a page that had some colorful images on it and some text, dependent on the domain name it was for. It annoyed the life out of me, especially because it would also, for example, happen to return that page instead of an image, or instead of sending the form you just filled in to the right server. Fortunately, I had already started the process of switching to a cheaper, faster, and less obnoxious provider.
FYI: the "obnoxious provider" in question is Orange. I live in the Netherlands - I don't know if they do the same in other countries. I have heard that they do the same on their ADSL lines, though.
It took me a while to understand that, until I realized he probably meant "manager". While I see the joke, I think it is insulting to managers in general. While some managers probably are jerks, I don't think insulting all of them is a good idea, and I would ask that you not do that.
``Just don't do stuff that others here have proposed - don't drop the certificates and certificate warnings completely, leaving only plain encryption. If you do this, then you basically have worthless encryption too, which is vulnerable to man in the middle attacks. What good is an encrypted channel if you have no idea whether the other side is the one you expect it to be?''
Well, at least it's encrypted. That means, supposedly, that whomever the channel runs to is the only one who should be able to decipher it in a reasonable amount of time. I really think this is useful by itself, and it's bad that browsers emit a warning when you do this - making it seem less secure than plain, unencrypted HTTP, because they don't emit a warning for that.
When I first discovered BitTorrent, I implemented a protocol called streamdist, which does something like this. It allows streaming of data to an arbitrary number of clients with only a single client getting the data from the server.
Of course, streamdist was just a primitive proof of concept, but this story sounds like I missed out on a couple of millions in funding.
``As for my bitching and moaning, it's well justified.''
Yes, but you are barking up the wrong tree.
It is not that the Linux developers don't want to support more 802.11[abg] chipsets.
It's that the chipset manufacturers don't want to work with the developers who would add support for their chipsets.
This is where it differs from the examples of Windows and OS X you give. For those, either the chipset manufacturers provide the drivers themselves, or they help those who develop the drivers by giving them specs (possibly under a non-disclosure agreement). For whatever reason, they are not willing to do the same for Linux.
Slashdot Mirror
``The point is, Microsoft created the technology and then it ended up in other browsers.''
No. They created something based on ActiveX.
Other browsers created a similar feature, which did pretty much exactly the same, but without ActiveX.
The feature that ended up in other browsers was not the same as the one Microsoft invented. The important difference between the two is that Microsoft's depends on Microsoft's proprietary ActiveX technology. This means AJAX is _not_ a non-proprietary innovation from Microsoft. What Microsoft came up with was proprietary. What ended up in other browsers was a knock-off with the proprietary lock-in parts replaced.
AJAX is not a case of Microsoft coming up with something that went on to become a standard. It's a case of Microsoft trying to lock people into their proprietary platform, and failing. The features were duplicated by the competition, and libraries were written that work with both Microsoft's and the rest of the world's implementation.
Now, there are actually examples of Microsoft creating standards. And I mean standards that don't lock you into their platform. AJAX is just not one of them.
Rough sketch of what I have been working on:
(I hope this is going to be formatted correctly. It looks ok in w3m...)
Confidentiality
Only the intended recipient is able to read the message. No government
spying.
Use public key cryptography. Encrypt the message with the public key of
the recipient. Only the holder of the corresponding private key can
decrypt the message.
Integrity
The message you send is the message they receive. No monkeying in the
middle.
Use message authentication codes. Encrypt a digest of the message with
the sender's private key. Verifying the authentication code proves that
the message has been sent by the purported sender and has not been
tampered with.
Authenticity
The message will say it's from Alice if and only if it was sent by
Alice. No spoofed From: lines.
See previous solution.
Roaming Access
Access your messages from anywhere. No fragmentation over several
systems.
Allow users to keep messages on the server. Store the user's keys on key
servers. Encrypt the private key, so that only an authenticated user can
use it.
8-bit Cleanliness
All 256 byte values should be allowed. No more base64.
Reputation System
Senders, servers, and recipients have reputations. Messages may receive
special treatment based on the reputation of their sources.
Users should be able to choose among various reputation services, so
that various methods for establishing reputations can be tried.
----
Protocol
- Textual
- Layered on TLS
- Server and client are authenticated using keys
- Sending message:
* Fetch recipient key
* Specify destination
- Server contacts destination server
- Server verifies destination account
- Server acknowledges destination
* Send headers (pubkey encrypted)
- Server forwards headers to destination
- Server acknowledges headers
* Send body (symmetrically encrypted)
- Server saves body
- Server acknowledges message
- Receiving message:
* Fetch headers
* Decrypt headers
* Send headers to reputation server
- Reputation server acknowledges headers
* Request body
- Server contacts sending server
- Server fetches body
- Server sends body
* Decrypt body
* If message is spam, report to reputation server
I have thought about this matter, and I think it is important to factor in how much data is an acceptable loss.
My /home is backed up every night, and backups are kept for 12 months. That means there are three ways I can lose data:
1. I lose it before it's been backed up. This applies to, at most, the last 24 hours of work I do.
2. I lose data after it's been backed up, and I don't notice for at least 12 months.
3. The data disappears from both the live system and the backup, before I can recover it.
2 is fairly unlikely. 3 is one that worries me, but I'm working on that by arranging my backup to be duplicated off-site. 1 is the one that bothers me the most. I imagine my harddisk failing on the day I just finished a large project, thus replacing the joy of having finished it by the pain of just having lost the final pieces.
What TFA talks about (losing data before it has been written to disk) doesn't worry me so much. I doubt I'd lose more than a few minutes of work that way. And I'd know that something had failed, so I would expect the data loss.
It gets more worrisome when you provide services to remote users. Imagine that you run an e-commerce website, and a customer has just placed an order and received a confirmation, and then your machine goes *poof* before the order has been comitted to stable storage. The customer would not be pleased, especially if they had already paid for the order.
I think, in cases like the e-commerce example above, you would want to make sure that changes had been recorded before telling anyone that they had. And now comes a question: is there any way I, as a programmer, can verify that something has been written to stable storage? Can I tell the system (library/operating system/database/whatever) "write this down and don't return to me before you've actually written it"? And preferably without writing _everything_ to stable storage.
For those who want to know what TFA says without actually reading it, it boils down to:
1. What you think you have saved and what has actually been written to stable storage may not be the same. In particular, things may still sit in DRAM, waiting to be written to disk.
2. What gets written to stable storage after the power failure may not be what was intended to be written. You could end up with corrupt data.
3. That's the hardware side of the story; software introduces many more hazards by lengthening the path between your actions and stable storage.
``I almost feel sorry for them.''
I might feel sorry for them if they had lost their position as totally-crushing-the-competition market leader in several segments.
For some reason, I first thought that this would be a competitor to the Eee and its ilk. A Freescale CPU in a netbook sounds like it could be good for battery life, although I wonder how much you can still save by putting in a more efficient CPU, really.
Then I realized this isn't like a netbook at all. It's more like what I think used to be called a "net PC", where you get, basically, a terminal that connects you to the Internet. This means that the real cost of using the computer is $250 plus the cost of extra devices you need, such as a monitor and a keyboard, plus Internet access, plus computation and storage.
I don't think this will fly. You can probably actually save money by buying a netbook, which comes with its own monitor, keyboard, and storage, and thus works with or without Internet access. You would also have your own data near you, instead of under the control of a company that may or may not charge you for it, may or may not provide you access to it tomorrow, and may or may not transfer it to others.
Not that I think the model where you have a dumb terminal and computation and storage happens elsewhere doesn't have its uses. Actually, I think thin clients are a really good idea. But a thin client shouldn't cost as much as $ 250 without monitor and keyboard, and I'm not convinced the world is ready for the computation servers to be on the Internet, not until we can establish more trust in service providers.
The case of the dutch public transport card has all the indications of nobody actually caring about the things most would consider good. There's been shoddy engineering from the beginning, that's why the system still isn't operational nationwide. The project is also ridiculously overspent, eating into taxpayers' money. If the contractor can't deliver for the price they mentioned, it should be their loss, not everyone else's. Security problems have been apparent for a long time, even though this is denied, ignored, and covered up. One positive effect of this is that the cards were found to contain far more personal information than necessary, allowed, and desirable. So, out of all the things they could have spent their resources on, they apparently chose tracking travelers and otherwise invading their privacy. On top of all that, I am not surprised at all that they would try to silence yet another couple of critics.
Really, this isn't about delivering a good product. I don't know what it _is_ about, but I do know it ends up spending tax payers' money on something that isn't good for them, especially if they travel by public transport. I'd very much like to see this investigated. Even if there wasn't any malicious intent, a lot of harm has been done. We need to know what happened, who ordered it to happen, and who allowed it to happen, because I don't want this to happen again. Sadly, I fear I won't get any sizeable part of the Dutch population to support such an investigation, let alone the government, which seems to have "no investigation into possible mistakes" their credo.
``Were I in their situation I would have publically released information on the hack the moment the injunction was overturned. If vendors of
ANY type of system want to fuck with people who show every intention of trying to HELP them, they deserve everything they get.''
Yes. But it's not they who get screwed over the most. It's the users of the system, those who paid for the system, and those who get caught abusing the holes.
In some parts of the world (notably the EU), PayPal is, indeed, regulated. Among other things, that means they can't simply lock your account at will. It's an interesting question why the same hasn't been done in the USA. And, actually, whether that's a Good Thing or a Bad Thing.
Isn't the fact that phosphorus stimulates algae growth, which suffocates other lifeforms, common knowledge? I seem to recall being taught this in school...
When I learned to program (I was 8), it was DOS and text mode and BASIC. The programs I wrote were simple "enter some text or numbers, get some response". It doesn't have to have fancy graphics and the like to be interesting.
And I'm not saying that because I'm an old fart. Everybody I know who programs started that way, although the younger folk usually started with GNU or BSD and Perl or Python, rather than DOS and BASIC. They do stuff that looks pretty uninteresting to non-programmers, but is very valuable to them. Usually, they start by automating something that they do often. Sometimes, they've found something they found cool (e.g. a script found on the web) and started tinkering with it. I had a book from the library with source code for a couple of simple games.
Another approach that can be very rewarding is web development. You can get impressive-looking results relatively quickly, and it scales all the way up to what the big guys are doing.
In the end, though, I think programming is something you have to want to learn. You may want your son to learn to program, and your son may be dreaming of making his own great game or operating system, but that's not enough. You need to develop the way of thinking that allows you to break down your idea into what you can express in your programming language, and that takes time and effort. It's going to be frustrating until you get it. Most people aren't really motivated to work through that, and will give up after a short while. That's ok. You can still learn to program when you are older, and you can be happy in life even if you don't ever learn to program at all.
Before the ad-supported Opera, however, people just used the evaluation version.
Money was never what stopped Opera's adoption.
What did stop its adoption is an interesting question, though. It has been a great browser for as long as I can remember - which I think goes back to version 3.something. I used it to test my websites, because Opera was much more picky and standards-compliant than the others. I also used it for my own browsing, because Opera was faster and offered a slew of useful features that other browsers lacked (tons of keyboard shortcuts and tabs being the main ones). Yet, I have never seen Opera at far above 1% in global browser market share stats.
Part of it is undoubtedly inertia. A lot of people will just use what comes with their system, which is probably some version of Internet Explorer or Safari, and perhaps Firefox (and, back in the day, Netscape). Part of it may also be explained by the multitude of websites that have been broken in ways that made them not work with Opera. If you use a lot of such websites, having to switch browsers constantly quickly gets old.
Myself, I stopped using Opera because of stability issues on Linux. Those might have been resolved now, but, nowadays, I run only open-source software on my main system. I am not about to make an exception for Opera; I am satisfied with Konqueror.
I disagree. I think agile development (not web 2.0 - whatever that is) is really a useful methodology. Rather than developing the product for an extensive period of time and finally confronting the customer with what you've cooked up, you periodically show them what you've made and let them provide input on future directions. As a customer, I would like that. I can see progress is being made, and I can spot early if things are going in a direction I don't like.
On the other hand, I have come to appreciate the waterfall model as well. It's good when you know in advance what you want, and it makes it easy to assign different people to work on different parts of the system. When done right, I think it can save a lot of overhead compared to agile development, and you know what you will finally end up with. As a customer, I would value that, because I can go about my business while the software is being developed by others. I'd still want to check on them once in a while, though; something that most customers I've dealt with actually don't seem to do.
So I think both models have their strength. Waterfall is good if you know or can determine in advance what you want built. You analyze the requirements, design the beast, and implement it, and if the specification was good and the devs and testers did their job, you'll have a product that does exactly what you ordered. Agile is good if you don't exactly know what you want. It fits an evironment where there is lots of innovation or competing products - you'll want to add features as you go, in response to changing ideas of what you think will drive customers to you. Waterfall is awful for that, because your product will be outdated by the time it is finished. On the other hand, agile doesn't give you much of an indication of what you will eventually end up with and what it will cost you.
I am so happy I found Debian. Upgrade your whole system with a single command. And if you run stable, you don't even get newer versions of software - you just get (backported) security fixes. Once it works, it just keeps working. It's almost a pity that a certain release will only be supported for a number of years...
``No, we can even measure how surface gravity varies from g=9.78 m/s2 to g=9.82 m/s2 when moving from the equator towards a pole. And this is because Earth is not perfectly round, the people at higher latitudes are closer to the center of Earth and fall faster.''
No, that's because they drink more alcohol there.
I've always thought it was a bad idea to include Real World phenomena in your SciFi universe, unless you know how said Real World phenomena work. At least, I find it very annoying when an author describes something in a certain way, and I know it doesn't work that way. It causes the suspension of disbelief to fail, which takes you out of the story, and you'll find yourself staring at a bunch of letters. Kind of like a BSOD shatters the illusion of having windows with documents in them.
How about these all-time favorites:
``That code is *not* easier to understand. I glanced at your post and thought "first bitwise XOR second"''
I understand where you are coming from, but really, what you're saying is a red herring. Had you known OCaml, it would have been immediately obvious to you what the code did. I considered for a while to use some hypothetical OCamll string concatenation function to prevent people from getting confused like you did, but, in the end, decided against it, because, in OCaml, you would just use the ^ operator. Anyway, as I said in my previous post, the fact that OCaml has an operator for string concatenation is besides the point.
The point is that the way OCaml handles strings allows string concatenation to be expressed succinctly and clearly, whereas, in C, one has to jump through hoops to get it right. This is where the programming language has an influence on the readability of the code. No matter how hard you complain about ^ not being the right symbol for string concatenation, the fact stands that in C, it cannot be expressed that clearly. You need some boilerplate code to do memory managment and check that you are actually passed strings and not NULLs. So, even if you know C, you will have to look at a couple of lines of code, until you figure out that what it actually means is "concatenate the strings first and second".
If it makes it easier for you to understand, feel free to imagine a hypothetical "strcat" function in OCaml, or an hypothetical language that is exactly like OCaml but uses whatever operator you prefer for string concatenation.
In a way, the languages, tools, and libraries prescribed (if any), also constitute a sort of coding practice, in the sense that they impose limits on how you can structure your code.
- The language you work with gives you certain language constructs. These constructs vary per language, and determine how you must express things and what abstractions are available to you. This has a huge impact on the structure of your code.
- Most tools like to structure and format your code a certain way, particularly when the tool generates the code. This is usually a great boon, because it will make it easy for programmers to adhere to the same coding standard and hard for them to deviate. Of course, if what you want is not what the tool wants, the tool starts getting in the way.
- The libraries you work with determine the APIs available to you. This also has a strong influence on the structure of your code. It also interacts with the language constructs available to you, as they may or may not make it easy to build an API you like to work with on top of the API that a library exposes.
Abstraction is particularly important. If a language offers powerful enough abstractions, you can structure your program so that it is easy for humans to understand what it does, and have the compiler translate it to whatever the libraries make available to you. Better abstractions also make your code more reusable.
As an example, in C, strings are character arrays. Arrays in C don't have a size associated with them. The end of a string is indicated by a character with value 0. Furthermore, the type of an array of characters is actually the same as a pointer to a character. C also doesn't have automatic memory management. Suppose now that you wanted to concatenate two strings. There are various ways to do so, but the most obvious one is the strcat function:
This function appends src to dest and returns dest (a pointer to the concatenated string).
That is, provided there was actually enough space in dest to hold the combined contents of dest and src, and the terminating NUL. If there wasn't, the function overwrites whatever came after dest, which will usually lead to your program crashing or executing code supplied by a cracker attacking your program.
The correct way to use strcat, then, is something like:
But wait! That's not all! Since the type of an array is actually a pointer, and pointers are allowed to be NULL in C, first and second in the above could actually be NULL. If either one of them is, the program will crash. So we need to add extra code to check for that ...
All those many things to remember to concatenate two strings. It doesn't have to be that way. In OCaml, for example, a string is a string, not a pointer to a character, and never null. You don't have to worry about allocating a large enough block of memory, because memory will be allocated as needed, and reclaimed when no longer reachable. As it happens, OCaml also has an operator that concatenates strings. That is besides the point here, but I had to tell you that to explain what the code looks like in OCaml. Namely:
Not only is it much shorter than the C code, it's also easier to understand what it does, and more robust.
I think this sort of thing matters a lot more than how you format or indent your code, and pretty much everything else that normally falls under the nomer of "coding standards".
Some ISPs will indeed show their annoying search pages even if the domain exists. I used to access the Internet via my phone and get redirected to a page that had some colorful images on it and some text, dependent on the domain name it was for. It annoyed the life out of me, especially because it would also, for example, happen to return that page instead of an image, or instead of sending the form you just filled in to the right server. Fortunately, I had already started the process of switching to a cheaper, faster, and less obnoxious provider.
FYI: the "obnoxious provider" in question is Orange. I live in the Netherlands - I don't know if they do the same in other countries. I have heard that they do the same on their ADSL lines, though.
``project mana-jerk''
It took me a while to understand that, until I realized he probably meant "manager". While I see the joke, I think it is insulting to managers in general. While some managers probably are jerks, I don't think insulting all of them is a good idea, and I would ask that you not do that.
``The CA's key is provided to Alice and Bob securely (i.e. when installing an OS or browser).''
This is secure?
``Just don't do stuff that others here have proposed - don't drop the certificates and certificate warnings completely, leaving only plain encryption. If you do this, then you basically have worthless encryption too, which is vulnerable to man in the middle attacks. What good is an encrypted channel if you have no idea whether the other side is the one you expect it to be?''
Well, at least it's encrypted. That means, supposedly, that whomever the channel runs to is the only one who should be able to decipher it in a reasonable amount of time. I really think this is useful by itself, and it's bad that browsers emit a warning when you do this - making it seem less secure than plain, unencrypted HTTP, because they don't emit a warning for that.
When I first discovered BitTorrent, I implemented a protocol called streamdist, which does something like this. It allows streaming of data to an arbitrary number of clients with only a single client getting the data from the server.
Of course, streamdist was just a primitive proof of concept, but this story sounds like I missed out on a couple of millions in funding.
Oh well.
``As for my bitching and moaning, it's well justified.''
Yes, but you are barking up the wrong tree.
It is not that the Linux developers don't want to support more 802.11[abg] chipsets.
It's that the chipset manufacturers don't want to work with the developers who would add support for their chipsets.
This is where it differs from the examples of Windows and OS X you give. For those, either the chipset manufacturers provide the drivers themselves, or they help those who develop the drivers by giving them specs (possibly under a non-disclosure agreement). For whatever reason, they are not willing to do the same for Linux.