The Korean on-line banking was starting to be implemented something like 12 years ago. Back then when Netscape was the dominant web browser, IE was something like 5.x, and there was no serious open-source alternative. Pretty much all the users were using either IE or netscape, so they couldn't force them to use some kind of in-house browser, nor afford to develop a new browser.

There once was a period that Netscape was supported, but no banks support it anymore because Netscape's market share turned to something close to zero.

I agree that the situation is pretty crazy because nowdays banks install mandatory 'keyboard protection' and 'anti-virus' plugins sort of stuff, which installs malware-like keyboard sniffing, system-crippling device drivers. Many people gets disgusted by this situation, but I sort of understand that the banks had no choice.
If somebody loses money even due to some client-side rootkit (such as keylogging), they still have the risk to be liable, and the court usually rules in favor of the victims.

The Korean on-line banking system is actually much more than merely SSL - every user has their own RSA certificate, their own passphrases, which expires every year. Signatures of the transactions are made on the client-side. Thus, simply having the password isn't enough to make a transactions - you need the certificate, the passphrase of the certificate, the password of the bank account, and finally, the password for logging in to the bank's website.

Is it that expensive on (insert your country name)?

Well, in Korea, I can remember at least two methods - bank transfer (with something like 50c transfer fee) or credit cards (call the credit card company for a temporary raise of your limit, which can only be used for that specific purpose).

Actually, I can't remember when was the last time I paid anything more than $100 in cash.

That probably would be because nobody manufactures 1GB PC2700 modules anymore.
Low demand -> lower supply -> even higher cost.

I agree that liability isn't a problem (you use it, you are responsible), but cost certainly is a problem.

The bare minimum to develop open-source hardware (assuming you want something with flashing LEDs, not simulation) is 1) a cheap FPGA board, and 2) a FPGA development tool. To do anything decent, you need to spend a couple of hundred of dollars for the board, but fortunately the tool comes free ('web edition'). This may be enough for developing something moderately complex - say a digital audio player.

However, if you want to develop something much larger, say something like a decently-sized microprocessor with some hardware acceleration, that's about 10k for the FPGA board and another 3k for tools. Add in some more tools, and it goes beyond your average hobby.

Of course some people can shell 20k for some hobby, but that results in a lack of users, and thus, collaboration (e.g. feedbacks, bug reports, contributions). If you are going to try some new software, the hardware cost you are going to spend is normally zero. If it doesn't work for you, you just wasted a day or two.

If you are going to try some new open-source hardware, that requires 10 grand. If it doesn't work for you, you wasted a whole month trying to build it, and all you have is an expensive piece of crap.

Well, I'm not quite sure if it will work well on ARM ISA. Most instructions starts with 0xe (unconditional operation), and 0xe[0-9a-f] isn't an alphanumerical character. Maybe instructions can be encoded using only conditional executions, but probably much more difficult (if possible) than x86.

Here in Korea, my mom's 14-year old Hyundai Sonata had something like 67,000km of mileage when she sent it to the junkyard. Although it is ridiculous even compared to other cars here, what I typically see from other cars around here is that the mileage is about 10,000 km per year, which is equivalent to about 30km per day.

And yes, due to the horrible traffic condition here, a 15km trip in the peak times take something like an hour.

Or even better, activate the compressors of the air conditioners only on bus stops. ...However, I'm sort of worried what will happen if the traffic jam is so horrible that the bus runs something around 5km/h, with constant acceleration/deacceleration.

There may be a point of removing the essay, but what will they replace with?

Ten years ago, when I seeked for university admission in Korea, a country which has extremely competitive university admission procedures, we had essay exams. They give you approximately 500~1000 words of whatever text (it can be some literature, news article, textbook text, or whatsoever), followed by a short question which has to be answered in a 1,600 character (around 500 wordsessay. With something like 2 hours time limit.

With only two hours, students had only something like 10 minutes to read the text, 5 minutes to think, 10 minutes to plan the structure of the essay, and about an hour to write 500 words on a piece of paper, including making correceionts. In other words, if you cannot understand the text and figure out what to write within 20 or so minutes, you are doomed.

Back then, and for many more years, I thought it was unfair. I wanted to do engineering, but the essay looked ridiculous. However, after ten years, I found that preparing for the essay exam had greatly enhanced my writing skills (which I find really important - sometimes more important than math or physics), and it forced me to read a lot of books of all sorts of topics.

I think these kind of essay exams (with tight time limits) may help, but unlike Korea, United States is a fairly large country, and it may be too difficult to have all the students seeking admision in one place.

Of course, that depends on who the user of the technology (such as, advertisement agencies), not the technology itself. The technology simply detects who is looking at the billboard, and how old the person is. It's entirely up to the ad agency to show adult dating sites or whatsoever on the billboard.

Thus, I think the ad agencies will end up putting ads that aren't so offensive to any demographic, anyway. Unlike popups from the web, it's intended to be placed on public space.

Password protection was supported for a long time, and is a part of the standard ATA specifiation. Although it typically has nothing to do with full-disk encryption, it was more or less enough to keep honest people honest, and add a little bit of cost+effort to bypass it.

Many RAID controllers use this feature to prevent the user from connecting a RAID-formatted hard drive to a normal ATA controller, thereby accidently destroying all data. Unlocking the drive is a non-issue, since they use the same password that you might find after a few minutes of googling, and if the RAID controller that locked it is available, you can unlock it without any problem.

Yes, it doesn't work. If you ever tried to design something using Verilog or VHDL, and tried to generate a real-world design, either an FPGA or a real chip, you will see that things aren't so easy.

I learned it the hard way, while doing my last year of undergraduate course. The simulation worked perfectly - correct input, correct output. On the other hand, making it work on the FPGA was a horrible, horrible, horrible job. Took 2 weeks of trying this, trying that, still with no clue.

Although the problem was a small behavior/synthesis mismatch, I found out that this was going to be a horrible job, because you may have bosses thinking just like you, and ask you to complete the implementation job by a few days. The truth is, that each synthesis job (equivalent to compiling) takes hours (if not days) to complete, and it is almost certain that it won't run on the first try. Believe me, there is a reason that there is a multi-billion dollar market for designing and verifying chips, where a huge portion of that is verification and debugging.

For firmwares, it is sorta similar state. You have to work around hardware bugs, e.g. you have to avoid calling some instruction that is supposed to work, and did work on simulation, because the processor screws itself when that instruction is called once every million time. The problem is, not calling that instruction may be possible, but identifying the problem gets really dirty.

Now I write simulators and models for simulation, rather than writing HDL code that should end up inside some FPGA or ASIC. I am much happier now, since Intel and AMD did a lot of work to verify and fix their dirty bugs, and I can trust the underlying hardware.

2,800lb flywheels, plus the related cirtuits, plus maintainence of the flywheel ain't cheap.

Plus, proper power capping can reduce infrastructure cost, since the power distribution/conversion whatsoever system in the datacenter needs to be designed according to the maximum load, which means they need a lot of headroom on their power supply. By doing so, they can reduce the maximum load.

The only problem... is how they will reduce power while minimizing the interruption to the workload on peak times. Not an easy job, but I don't think it would be impossible. We should try, at least.

It is common to deliberately add a check that breaks the whole stuff when some 'unexpected' condition happens. You know, assertions.

Which one is better? Not working at all, or seems like working but a not-so-commonly-used-some-sort-of-admin-command somehow gets screwed and the web browser fires a do-not-touch-this-unless-you-want-complete-meltdown-command because there was some minor difference on the javscript engine parsing some parameters? Yeah, can be extremely rare, but if it isn't tested, nobody can be sure.

Obviously, the best thing to do would be to test all possible conditions. However, if you can't, then there can be three choices:

1) Leave it to the users, Nah, I'm not gonna test it.
2) Launch a big warning message and blame the users if something goes wrong, or
3) Make it never work when some unknown condition is reached.

Number 1 is perfectly reasonable when the worst consequence isn't so bad. For example, a web forum interface, or things like Facebook. Maybe number 2 would be better in most cases. But, if an untested scenario may cause huge, irrecoverable damage, number 3 may be the best choice. (You should remember that the product in question was the server management console, which can bring the whole datacenter down when things go wrong.)

My opinion is that, deliberately excluding Opera was a quite reasonable idea. Trying to sell a product that deliberately excludes Opera (web browser) to Opera (the company) was the stupid idea.

So is the TV, public schools, parents, friends, and whatever. You can even brainwash yourself.

Having gone through Boot Camp myself (Not in United States, I live in a country where millitary service is mandatory) I also highly recommend it as a means of turning useless people into productive citizens. On the other side, it is a good way to turn useful people into far less productive citizens.

My opinion is that, the main goal of the boot camp is to create an average person, not too smart, not to dumb, not too hardworking, not to lazy, etc. Transforming normal people into standardized soldiers.

The problem is, that when that person returns to his original environment, it doesn't take so long to see a 'standardized' person to return to his normal lifestyle. I saw numerous friends who found out 'how lazy they were, and how worthless they were' on the boot camp, and found that they also can achieve things if they try hard enough. However, after finishing their millitary service and returning to their original environment, it didn't take long to return to their original life pattern.

What I saw, along with many other people saw, was that game addiction, and probably web addiction, is an symptom of other problems, not itself being the problem. Those guys may have problem with their friends, their school, their parents, or whatsoever. Sending them to the boot camp may solve some of them (no more school, no more previous friends, and no more parents yelling at you), but once they are out of the boot camp, everything returns to the previous state.