I believe that we're going to see a performance plateau with processors and raw CPU power for the next 5 years or so.
The only way CPU manufacturers are going to get more *OPS in the future is with many cores, and that's going to require either slower or the same kind of speeds (GHz-wise) as things are today. To get programs to run faster under these circumstances you need some kind of explicitly parallel programming.
We haven't seen the right level of parallelism yet, IMHO. Unix started out with process-level parallelism, but it looks like thread-level paralellism has beaten it, even though it is much more prone to programmer errors.
On the other end of the scale, EPIC architectures like Itanium haven't been able to outcompete older architectures like x86 because the explicitly parallel can be made implicit with clever run-time analysis of code. Intel (and, of course, AMD) are their own worst enemy on the Itanium front. All the CPU h/w prediction etc. removes the benefit of the clever compiler needed for EPIC.
Maybe some kind of middle ground can be reached between the two. Itanium instructions work in triples, and you can effectively view the instruction set as programming three processors working in parallel but with the same register set. This is close (but not quite the same) to what's going to be required to efficiently program multi-core CPUs, beyond simple SMP-style thread-level parallelism. Maybe we need some kind of language which has its concurrency built in (something sort of akin to Concurrent Pascal, but much more up to date), or has no data to share and can be decomposed and analyzed with complete information via lambda calculus. I'm thinking of the functional languages, like ML (consider F# than MS Research is working on), or Haskell.
With a functional language, different cores can work on different branches of the overall graph, and resolve them independentantly, before they're tied together later on.
It's hard to see the kind of mindset changes required for this kind of thinking in software development happening very quickly, though.
1) Bloggers who blog because they think it's a new medium which will change the world: the "professional bloggers". scripting.com, Doc Searls, Scoble etc. I don't have much time for these guys.
2) Blogs which are essentially self-published syndicated opinion columns: Tom Barnett, gapingvoid, certain slices of the msdn blogs (Old New Thing, Larry Osterman, Mike Stall, Brad Abrams), Larry Lessig, etc. These are the best, and aren't necessarily blogs-for-the-sake-of-blogs, but simply online thought dumps from people on the front line of their area of expertise.
3) Everything else. I haven't read any of these blogs, but I keep hearing about them, in a sort of random way.
Yes. The Microsoft version is CreateActiveX("XMLHTTP"), the Firefox / Safari version is new XMLHttpRequest(), AFAIK. I'm not an expert in client-side Javascript, though: I just do the server stuff.
Unfortunately, that's not all it is. It tries to dictate how you write your application, and expects every application to basically look like a web application, with back and forward buttons, and a page navigation model.
I can't see XAML taking of in its current shape, not without some serious pruning.
If your Javascript is generic, and simply links your form input elements to do immediate postback to the server (XMLHttp, somewhat similar to Gmail), you get code reuse.
Common validation patterns can be encapsulated into Javascript and sent down to the client either dynamically or via a "selector" parameter (e.g. masks, datatype). You can do this by sending a dictionary of information about the form to the client from the server (again, via XMLHttp).
If you do this right, your static HTML will only need IDs to be set on elements, and include a common Javascript library in its onload.
That's how we build applications where I work. I do all the server side stuff to make it happen.
From the blog itself, the first entry (at the end of the PDF, it's in reverse chronological order):
While this is intended as an internal blog, I recognize that it will become public--welcome to the Internet! As a result, please recognize that I may be a bit limited in my comments and responses to protect Intel, and that we may exercise some editorial privilege on your comments for the same reason. I want to be clear on this up front. This is the price of entry to this blog.
Mercury News is putting quite a spin on this "internal" stuff.
For mixed Windows API-managed code programming, I like C++/Java better than C++/C# because to access C# modules from Windows API C++, you have to go through a lot of Windows jive with the GAC and other bits of Klingon language. Connecting C++ and Java through the JNI seems easier to me than connecting unmanaged C++ to C#.
I think that's a specious argument designed simply to prove yourself correct. If I were integrating unsafe, unverifyable C++ with.NET, I wouldn't use unmanaged C++.
... in some cases, taxis are hired by the hospital (government owned, dept of health) to drive x-ray photos *across the country*; for example, from Galway to Dublin, a journey on our roads that takes about 3.5 hours.
And that's just for one set of photos. No batches or big bundles of photos, or any kind of optimization.
Oh come on. Not many people have enough photos and MP3s to fill even 10GB nevermind 120GB or 160GB.
MP3s and photos aren't the issue. Videos are. Many people I know (a lot of non-techies among them) record large quantities of home video. 200GB+ per year is currently easily on the table.
And when digital video get even cheap and even more disposable, the amount of media entering the average home PC is just going to increase.
The CV's job is to get you to an interview. Re honesty, I'd certainly tell the truth, but it would be best to omit those things that come under the heading "brutally honest": in an interview you can explain those missing bits face to face, but on a CV it just becomes a reason not to interview you.
The group that decides on patents only meets every 6 months. The Dutch presidency wants to achieve as much as possible in its presidency, so the directive was put into a free slot in this meeting.
The torrent points to the tracker. It's the tracker which is in a vulnerable position (not to mention the fact that it gives out the IPs of clients ready to feed data).
Essentially, the torrent is just a link to the tracker with hashes of bits that make up the file.
I reckon he's going to do something in the area of podcasting. If you listen to his podcast show, The Gilmore Gang, you'll have heard that he's been giving off hints of this for some time now.
He sees podcasting as becoming a mainstream slice of the media pie in the future, much like newspapers, radio, TV and the WWW already are, but in a much more democratized fashion.
I.E.: There won't be so much hegemony of a few media moguls over vast empires of dominant, dogmatic opinion. Instead, little shows from the "little people", each in their niche, will bring media back to the people who consume it.
if they only have closed-source drivers then they're at the mercy of the vendor
Open-source drivers should exist in a competitive environment with closed-source drivers - this will improve the quality of both. Nothing stops people from developing an open-sourced driver when a closed-source driver already exists. If they do, it's because the open-source driver is of poor quality and doesn't deserve to be used, and that's a poor excuse to avoid competition.
Performance, ease of use, stability: I'm happy with Windows in all those areas for native Windows applications.
The reason I want to use Linux is because I don't have to pay MS extortion fees for licenses. The economic argument is the only argument which will get businesses to switch.
Home users won't switch because of games. Games won't switch because of modern (i.e. this morning's) hardware not being supported well enough. Modern hardware won't be supported well enough because there isn't a stable binary API for the kernel and X which the hardware companies can target with closed-source drivers.
(And also because the fork() syscall works faster in Linux than it does in Cygwin.)
The trouble with this fact (new hardware not supported) is that people like me (I upgrade once or twice a year) can never get a decent, stable distribution running on their desktops.
Thus, for all intents and purposes, Linux hardly supports any system (i.e the whole entire sum of the box's hardware) I've ever used, at the time I was using it.
I strongly believe Linux will never work on the desktop unless there is a stable *binary* API for both kernel drivers and X video drivers that companies can target.
More on-topic:
I live in MS Visual Studio (50%), Cygwin (20%) and Firefox (15%) (sundries remainder). The closest thing to VS on Linux is Kylix, which is pretty much abandonware - perhaps something will emerge from Mono/SharpDevelop. Having the same applications available on both platforms is, IMNSHO, the only workable strategy to migrate users to Linux.
Imagine a Big Bang approach: everybody comes into work on Monday morning to a completely new set of applications that they've never used before! You'd need to be in fantasy land to think that scenario would work!
The only way it can be done is by minimizing the difference between the two platforms, so that it becomes purely an economic argument.
Stability etc. don't and won't fly. X drivers in my experience have been far, far more flaky than Windows drivers for my (new) video hardware. It's probably the X driver that matters most on the desktop. X is the average Linux distribution's worst "feature". I compulsively set inittab to runlevel 3 rather than submit to that torture.
[I've been modded Troll for stating my honestly-felt opinions about the shortcomings of the current Linux desktop situation. Too many Linux zealots are afraid of the opinions of the very users they wish to convert, and their defensive rage hurts their case more than they know.]
It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not.NET or Java), it's possible to do so with no performance impact at all in all ISO compilers.
It is actually easier in.NET . The JIT compiler handles all the inlining automatically. It will probably end up faster than anything C/C++ can produce due to the pointer aliasing issues that those languages have to deal with.
Slashdot Mirror
I believe that we're going to see a performance plateau with processors and raw CPU power for the next 5 years or so.
The only way CPU manufacturers are going to get more *OPS in the future is with many cores, and that's going to require either slower or the same kind of speeds (GHz-wise) as things are today. To get programs to run faster under these circumstances you need some kind of explicitly parallel programming.
We haven't seen the right level of parallelism yet, IMHO. Unix started out with process-level parallelism, but it looks like thread-level paralellism has beaten it, even though it is much more prone to programmer errors.
On the other end of the scale, EPIC architectures like Itanium haven't been able to outcompete older architectures like x86 because the explicitly parallel can be made implicit with clever run-time analysis of code. Intel (and, of course, AMD) are their own worst enemy on the Itanium front. All the CPU h/w prediction etc. removes the benefit of the clever compiler needed for EPIC.
Maybe some kind of middle ground can be reached between the two. Itanium instructions work in triples, and you can effectively view the instruction set as programming three processors working in parallel but with the same register set. This is close (but not quite the same) to what's going to be required to efficiently program multi-core CPUs, beyond simple SMP-style thread-level parallelism. Maybe we need some kind of language which has its concurrency built in (something sort of akin to Concurrent Pascal, but much more up to date), or has no data to share and can be decomposed and analyzed with complete information via lambda calculus. I'm thinking of the functional languages, like ML (consider F# than MS Research is working on), or Haskell.
With a functional language, different cores can work on different branches of the overall graph, and resolve them independentantly, before they're tied together later on.
It's hard to see the kind of mindset changes required for this kind of thinking in software development happening very quickly, though.
We'll see. Interesting times.
It's not very good. I'd estimate it has about 70% success rate at blocking flash. Sites with multiple flash elements often get through.
Also, the "play" button it puts up is itself animated: not a good thing in something designed to minimize the distraction of flash ads.
There are at least three classes of blogs:
1) Bloggers who blog because they think it's a new medium which will change the world: the "professional bloggers". scripting.com, Doc Searls, Scoble etc. I don't have much time for these guys.
2) Blogs which are essentially self-published syndicated opinion columns: Tom Barnett, gapingvoid, certain slices of the msdn blogs (Old New Thing, Larry Osterman, Mike Stall, Brad Abrams), Larry Lessig, etc. These are the best, and aren't necessarily blogs-for-the-sake-of-blogs, but simply online thought dumps from people on the front line of their area of expertise.
3) Everything else. I haven't read any of these blogs, but I keep hearing about them, in a sort of random way.
Yes. The Microsoft version is CreateActiveX("XMLHTTP"), the Firefox / Safari version is new XMLHttpRequest(), AFAIK. I'm not an expert in client-side Javascript, though: I just do the server stuff.
I'm not sure XAML will be that successful.
As a rendering and composition engine, it's OK.
Unfortunately, that's not all it is. It tries to dictate how you write your application, and expects every application to basically look like a web application, with back and forward buttons, and a page navigation model.
I can't see XAML taking of in its current shape, not without some serious pruning.
-- Barry
If your Javascript is generic, and simply links your form input elements to do immediate postback to the server (XMLHttp, somewhat similar to Gmail), you get code reuse.
Common validation patterns can be encapsulated into Javascript and sent down to the client either dynamically or via a "selector" parameter (e.g. masks, datatype). You can do this by sending a dictionary of information about the form to the client from the server (again, via XMLHttp).
If you do this right, your static HTML will only need IDs to be set on elements, and include a common Javascript library in its onload.
That's how we build applications where I work. I do all the server side stuff to make it happen.
-- Barry
From the blog itself, the first entry (at the end of the PDF, it's in reverse chronological order):
While this is intended as an internal blog, I recognize that it will become public--welcome to the Internet! As a result, please recognize that I may be a bit limited in my comments and responses to protect Intel, and that we may exercise some editorial privilege on your comments for the same reason. I want to be clear on this up front. This is the price of entry to this blog.
Mercury News is putting quite a spin on this "internal" stuff.
I wonder if this will be used by various guerilla groups to try and even up the technological battleground.
For mixed Windows API-managed code programming, I like C++/Java better than C++/C# because to access C# modules from Windows API C++, you have to go through a lot of Windows jive with the GAC and other bits of Klingon language. Connecting C++ and Java through the JNI seems easier to me than connecting unmanaged C++ to C#.
.NET, I wouldn't use unmanaged C++.
I think that's a specious argument designed simply to prove yourself correct. If I were integrating unsafe, unverifyable C++ with
... in some cases, taxis are hired by the hospital (government owned, dept of health) to drive x-ray photos *across the country*; for example, from Galway to Dublin, a journey on our roads that takes about 3.5 hours.
And that's just for one set of photos. No batches or big bundles of photos, or any kind of optimization.
Oh come on. Not many people have enough photos and MP3s to fill even 10GB nevermind 120GB or 160GB.
MP3s and photos aren't the issue. Videos are. Many people I know (a lot of non-techies among them) record large quantities of home video. 200GB+ per year is currently easily on the table.
And when digital video get even cheap and even more disposable, the amount of media entering the average home PC is just going to increase.
The CV's job is to get you to an interview. Re honesty, I'd certainly tell the truth, but it would be best to omit those things that come under the heading "brutally honest": in an interview you can explain those missing bits face to face, but on a CV it just becomes a reason not to interview you.
So, be conservative with the truth. IMHO.
Uh, because floe comes via Norwegian from old norse for layer, while flow is an older English word, more related to water, tide, liquids, etc.
It kinda was being pushed through the back door.
The group that decides on patents only meets every 6 months. The Dutch presidency wants to achieve as much as possible in its presidency, so the directive was put into a free slot in this meeting.
It looks like some kind of "stylish" breadmaker or something. Or maybe some kind of portable microwave.
Or a prop for a near-future film designed to contain some radioactive fuel or other stuff which needs an active container.
There are products already in the field which are designed to keep the wireless network from leaking out of the building.
This product looks like it'll be good for tracing down those leaks.
The torrent points to the tracker. It's the tracker which is in a vulnerable position (not to mention the fact that it gives out the IPs of clients ready to feed data).
Essentially, the torrent is just a link to the tracker with hashes of bits that make up the file.
I reckon he's going to do something in the area of podcasting. If you listen to his podcast show, The Gilmore Gang, you'll have heard that he's been giving off hints of this for some time now.
He sees podcasting as becoming a mainstream slice of the media pie in the future, much like newspapers, radio, TV and the WWW already are, but in a much more democratized fashion.
I.E.: There won't be so much hegemony of a few media moguls over vast empires of dominant, dogmatic opinion. Instead, little shows from the "little people", each in their niche, will bring media back to the people who consume it.
Or something like that.
I'm all for free code when it's better than closed-source code, but I won't eat shit just because it's free shit.
I also think that shifting the mindset of business (especially management) away from the MS licensing model would be a good thing.
if they only have closed-source drivers then they're at the mercy of the vendor
Open-source drivers should exist in a competitive environment with closed-source drivers - this will improve the quality of both. Nothing stops people from developing an open-sourced driver when a closed-source driver already exists. If they do, it's because the open-source driver is of poor quality and doesn't deserve to be used, and that's a poor excuse to avoid competition.
Performance, ease of use, stability: I'm happy with Windows in all those areas for native Windows applications.
The reason I want to use Linux is because I don't have to pay MS extortion fees for licenses. The economic argument is the only argument which will get businesses to switch.
Home users won't switch because of games. Games won't switch because of modern (i.e. this morning's) hardware not being supported well enough. Modern hardware won't be supported well enough because there isn't a stable binary API for the kernel and X which the hardware companies can target with closed-source drivers.
(And also because the fork() syscall works faster in Linux than it does in Cygwin.)
The trouble with this fact (new hardware not supported) is that people like me (I upgrade once or twice a year) can never get a decent, stable distribution running on their desktops.
Thus, for all intents and purposes, Linux hardly supports any system (i.e the whole entire sum of the box's hardware) I've ever used, at the time I was using it.
I strongly believe Linux will never work on the desktop unless there is a stable *binary* API for both kernel drivers and X video drivers that companies can target.
More on-topic:
I live in MS Visual Studio (50%), Cygwin (20%) and Firefox (15%) (sundries remainder). The closest thing to VS on Linux is Kylix, which is pretty much abandonware - perhaps something will emerge from Mono/SharpDevelop. Having the same applications available on both platforms is, IMNSHO, the only workable strategy to migrate users to Linux.
Imagine a Big Bang approach: everybody comes into work on Monday morning to a completely new set of applications that they've never used before! You'd need to be in fantasy land to think that scenario would work!
The only way it can be done is by minimizing the difference between the two platforms, so that it becomes purely an economic argument.
Stability etc. don't and won't fly. X drivers in my experience have been far, far more flaky than Windows drivers for my (new) video hardware. It's probably the X driver that matters most on the desktop. X is the average Linux distribution's worst "feature". I compulsively set inittab to runlevel 3 rather than submit to that torture.
[I've been modded Troll for stating my honestly-felt opinions about the shortcomings of the current Linux desktop situation. Too many Linux zealots are afraid of the opinions of the very users they wish to convert, and their defensive rage hurts their case more than they know.]
It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not .NET or Java), it's possible to do so with no performance impact at all in all ISO compilers.
It is actually easier in .NET . The JIT compiler handles all the inlining automatically. It will probably end up faster than anything C/C++ can produce due to the pointer aliasing issues that those languages have to deal with.
If you whip up domain-specific languages (DSLs) often, ANTLR is an excellent tool for writing lexers and parsers and tree parsers.
(Tree parsers parse the syntax tree generated by the parser (optional) for doing multi-pass semantic / compile checks, for example.)
Once you've learned the techniques for DSLs you start to use them everywhere, especially in large architectural design).