Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re: How the hell does this get into live software? (Score 4, Interesting) 129 129

The bug is stupid. No doubt about that. But it's not quite as stupid as you think.

The bug is not actually in the setuid application, but it is in the system wide dynamic loader that is needed to execute the setuid application.

So, a naive programmer could be excused to think that they don't need to worry about security as it is not immediately obvious that the code executes with elevated privileges.

Of course a more seasoned developer should have noticed. It's not that difficult to spot, especially as dynamic loaders are known to have had security bugs before. I think even Linux was affected at one time.

Comment Re:Web Workers (Score 1) 175 175

WebWorkers allow multiple threads of execution, but they don't support a shared address space. For some applications this is acceptable. For others, not so much.

And for any application that previously existed as a C++ application using pthreads, WebWorkers just don't work at all.

WebAssembly is working on a solution to this problem. This is one of the most exciting features that WebAssembly promises.

Comment Re:Different languages (Score 1) 175 175

JavaScript has a couple of really ugly warts (I'm surprised you mentioned variable hoisting, but left type coercion out), but fortunately with a little bit of discipline most of these issues can be avoided quite easily.

It is extremely flexible, and you can implement a large variety of programming paradigms with it. Unfortunately, it lacks some of the syntactic sugar to make this easy. So, short to medium size programs usually work great. Larger programs get cumbersome at some point.

Fortunately, there are all sorts of pre-processor style languages that can help with this. And browsers have source maps these days, so that's even reasonably seamless.

As far as embeddable language, JavaScript is overall not a bad design. Not surprisingly, it made a lot of the same trade-offs that other embeddable languages (e.g. Lisp or LUA) did. It is deceptively simple, but sufficiently different that it is really easy to falls into the trap of not learning it properly and trying to write JavaScript as if it was C++ (or Java, or ...). I suspects that's the main reason why people don't like it.

On the positive side, it made a couple of decisions that paid off really well. First and foremost its decision to only ever have a single thread of execution really stands out. This makes it much easier to write a secure virtual machine, and that's really the most important question when embedding a language in a web browser; of course, the single thread of execution also is the one thing that gets into the way when taking existing non-JavaScript code and trying to execute it in a JavaScript VM. WebAssembly is an attempt to bridge this gap.

Comment Re:I don't think it will gain much traction (Score 4, Informative) 175 175

That is possibly true, although details will still need to be seen. asm.js programs typically allocate a single static memory region that they than manage themselves without bothering the JavaScript VM to track memory references. In fact, a asm.js program doesn't have access to garbage collected objects. As soon as it tries to access those, it falls back to JavaScript mode (every asm.js program is by definition also a valid JavaScript program, but not necessarily vice versa).

WebAssembly programs at least originally will do the same as asm.js. It is possible that as more experienced is gained with this feature, there will be a way for WebAssembly to tap into the garbage collected pool of objects. Only time will tell.

Comment Re: Webassembly means... (Score 2) 175 175

6502 is a very restrictive architecture. This wasn't too bad, when problems were usually trivial enough that 8 bit operations or at best 16 bit operations were needed the bulk of the time. But for any non-trivial problem these days, that's just not the case. And the limitation of a single general purpose register, a 256 byte zero page, a 256 byte stack and almost no addressing modes is just way too restrictive, if you want to start writing your programs in a high-level language; if you write tiny trivial hand-optimized assembly programs, that might not be obvious.

On top of that, the tiny address space made it impossible to write anything but the most trivial applications (by today's standards).

For simple programs written during that time period, the code was reasonably dense, but certainly not ground breakingly so. If you tried to write any modern programs, you'd be wasting a lot of space emulating 32 bit (or wider) operations, switching memory banks, and figuring out how to work around the lack of an FPU; let alone a MMU. The code would be horribly verbose.

x86 is actually not horribly bad by modern standards. It is almost the most compact encoding that anybody has managed to come up with, and that's a good thing. These days, memory bandwidth is a serious bottle neck and as a first approximation, the more compactly the compiler can encode your program, the faster it'll run. Code density is one of the driving forcing in going from asm.js to WebAssembly. asm.js is intrinsically verbose, but relies on compression to fix this issue.

On the other hand, WebAssembly will have its own dense binary encoding. The encoding is probably not going to look very similar to traditional instruction sets, but instead mimic the internal representations used by compilers and JIT based virtual machines (such as modern JavaScript implementations). It is expected to be very dense, so that even bit web applications load quickly. But as far as I can tell, the binary format hasn't been finalized yet; in fact, I don't think there are any detailed proposals yet. Although that might have changed since I checked a few weeks ago.

Comment Re:Emscripten (Score 1) 175 175

Exactly. Think of asm.js as the proof-of-concept and WebAssembly as the production-ready solution.

asm.js was a very valuable first step to get the browser vendors on board. But WebAssembly will push much further. Most importantly, it intends to support POSIX threads for languages such as C++. That's something that asm.js never knew how to address.

Comment Re:I don't think it will gain much traction (Score 3, Informative) 175 175

An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.

Comment Re:Different languages (Score 3, Insightful) 175 175

JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.

But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.

Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.

Comment Re:Webassembly means... (Score 3, Interesting) 175 175

You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.

But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.

The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.

This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.

Comment WebAssembly (and asm.js) solved the boot strapping (Score 4, Informative) 175 175

Previous attempts at replacing JavaScript always suffered from a boot strapping problem. While there are only a small number of major desktop browsers, overall, there are actually a lot of different minor browsers that people expect to work. And even among the desktop browsers, not everybody always runs the most recent release.

Content producers don't really like writing content that only 30% of their users can view. So, unless a new technology is rolled out to 90+% of the deployed browsers, nobody is going to write content for it. On the other hand, if nobody writes content, the rest of the browser manufacturers won't put any resources into adding support for the new technology.

Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers. Performance will obviously be degraded, but that's much better than making the content completely inaccessible. And users are more likely to upgrade their browsers, if they can see a low-fidelity version of the content and know by switching to a newer browser they'll get the high-fidelity version. So, unlike the previous scenario, this is actually a virtuous circle.

Comment Where are the round-abouts (Score 4, Insightful) 203 203

I am always surprised that American cities don't learn from the rest of the world and install round-abouts instead of intersections. Many European countries have been aggressively converting their intersections to traffic circles; and they found that accident rates go down, throughput goes up, there are zero operating costs (i.e. no need for traffic lights), and often the round-about needs the same or even less space than traditional intersections.

It takes a little bit of time for everybody to get used to the new design -- and that means both city planners, drivers, and pedestrians. But in the end the benefits are very obvious.

Comment Re:Easy solution... (Score 1) 281 281

Have you tried calling Microsoft's customer support about this? In the past, they have always been super friendly whenever I talked to them. They know that their licensing is super confusing and it is easily possible to trip up the automated license enforcement mechanisms. But in my experience they are usually willing to work with you. If your complaint sounds at least somewhat plausible, they will either figure out how to undo the damage you did, or they will send you a new license.

Of course, if you just make up bull shit to try to get a free license for the copy of Windows that you downloaded from Bittorrent, don't expect that they'll be able or willing to help.

Comment Re:My LED bulb didn't last! (Score 1) 328 328

I converted the whole house to LED about a year or two ago. And yes, that required rewiring some of the fluorescent fixtures. It's generally not a big deal, although it took a bit of effort to rewire the fixture in our range hood. Thank God for pop rivets :-)

But I just saw that Home Depot has started selling LED lights that apparently are compatible with electronic ballasts. They no longer require rewiring of the fixture. I am a little skeptical and haven't tried them myself, but Home Depot has an excellent return policy. So, if I had any remaining fluorescent fixtures that needed converting, I'd probably give the Home Depot product a try first.

"It's what you learn after you know it all that counts." -- John Wooden