It just goes to show that the reason that IE got to have so much dominance was not because it was bundled with the operating system, but that for far too long it had no real competition.
I rather think that it means you're looking at the data too late. Of course MSIE was the dominant browser when it didn't have any real competition, but that was after the competition had been killed off. Before that, there was healthy competition between Microsoft Internet Explorer and Netscape Navigator.
Although it is impossible to say for certain, many believe that MSIE came to have ~90% market share through a combination of being bundled with the operating system and having become good enough that it wasn't worth the trouble to get a different browser. Netscape went under and it would take years for Mozilla to produce something that people would actually prefer over MSIE, but all this time, there had been Opera, who have made a very impressive browser at least since their 3.x days. Why is it that they never managed to sway a large percentage of users? Could it be because Opera, other than Netscape and IE, was never included on ISPs installation disks, included with shareware magazine's distributions, or bundled with operating systems on large scale?
Recent history also tells some interesting stories. At some point, Microsoft apparently got worried enough about the competition on the browser front that they created an Internet Explorer team again. Yes, they had actually disbanded the IE team after the release of IE 6. So what did the competition have to do to get back in the game? Well, take a look at Firefox, Opera and Safari from around Firefox's 1.0 release, and you will find that they are light years ahead of MSIE 6 - which really isn't all that different from MSIE 5.5. Let's also not forget that Firefox had a stable base on *nix, and Safari on Mac OS X, so they would continue to be improved regardless of adoption by Windows users.
Does bundling a browser with the operating system (or ISP service) give that browser a huge advantage over the competition? I think it is clear that it does.
``maybe this should be taken as a sign that the problem NX solves needs a different solution. Like, oh I don't know... maybe revising the X windows protocol so it doesn't suck so hard it has its own event horizon?''
Yeah, maybe. Of course, this has been tried many times before, and not with much success, I believe.
The truth to the matter is that the X protocol is actually pretty good. It's the software that implements it that could be better. That at least used to be true of both servers and Xlib (range checks, anyone?), as well as clients. If you think X is slow, it is almost certainly because you are using a client that causes a lot of network round trips and waits for them. There is absolutely nothing in the X protocol that forces you to do so. But if you do so, then, yes, your app will be very slow over a moderate-latency link.
Indeed, usually, the slowness in X is caused by network latency (the exception being if you are rendering a lot of pixels, e.g. for movies). Moreover, the slowness is often not inherent in the X protocol, but rather caused by how an application uses it. Some X clients are amazingly fast, even over moderate latency links.
This is also why you often get a more responsive UI by using something that just pushes pixel data, like VNC, instead of X. They work faster, even though they are less efficient in terms of amount of network traffic. It's not the throughput, it's the latency.
You could actually do the same thing with X: just render your whole app to an XImage, then render that to the server. This will be faster than synchronously performing all your drawing operations over the network, if you do lots of drawing operations. On the other hand, if you have lots of images that you tend to reuse, store them on the server as XPixmaps, and then you can render them faster than you could by pushing the pixels each time. X offers you this choice, and when used well, can actually be _faster_ than other technologies over any kind of network. The only thing I haven't found is a way to compress pixel data, but perhaps that is just because I haven't looked hard enough.
Perhaps I don't remember it right, but in my recollection, NoMachine has always been a bit possessive with their (definitely impressive) technology. To the point that lesser alternatives have continued to be used and even developed.
I haven't been following the events here so far, and a little searching yielded a lot of words that I am not familiar with and not a lot of insight. Could someone explain what the issue is here?
As far as I have been able to tell, the focus is on the licensing terms for the TCK, and the TCK is a test suite for existing and proposed Java standards. Oracle owns the rights to TCK and will not license it to the Apache Software Foundation under terms that the ASF will agree to.
Assuming that I have that right, so what? It's Oracle's software; they can choose to license it as they see fit, right? I _thought_ that passing the TCK's tests was necessary for being allowed to call your stuff "Java", but searching the web, I didn't find anything that supported that. So, correct me if I'm wrong, but as far as I can see, ASF is not being restricted in what they can and can't do.
Another point of view is that WikiLeaks had best inspect what they release, and do their best to prevent putting lives at risk, especially those of innocent bystanders and those who are working for the greater good. They're damned if they do and damned if they don't: if they take their time to filter and redact, they are delaying and possibly twisting the truth, but if they don't do that, they are irresponsible.
``I'm certain more details will come out as people have more time to go through these documents. But so far what I've found most surprising is how unsurprising these documents are. So the US is spying. Big fucking deal, everybody spies. This isn't news.''
That's what I would think, too. So what _is_ the big deal here? Obviously, there is a big deal, otherwise governments wouldn't get so upset over it.
``Our governments need accurate information, not self-censored tripe.''
Yes, I very much agree. And so do our populations. And in neither case are insults and offensive wording very helpful.
So there are several things here. First of all, having a good view of the whole picture is crucial to making the right decisions. Secondly, rousing emotions and withholding part of the information impedes getting a good view of the whole picture.
What I have seen from the US government in the last, say, 10 years, has been quite a bit of playing on emotions, withholding information, and even outright lies.
Two wars were started. Osama Bin Laden has not been caught, and terrorists are still active. No weapons of mass destruction have been found in Iraq that I am aware of. The USA declared victory in Iraq, and I think most of the bloodshed has actually come after that point.
The real number of casualties, the crimes against humanity, the existence of certain prisons and the interrogation methods being used there have all been swept under the rug by the USA and its allies.
WikiLeaks has been showing the world what has really been going on. The fact that they can _shock_ the world by releasing a video of military personnel shooting civilians is telling to me. It looked like a tragic accident to me. This is what war is really like. Such accidents happen.
Other releases by WikiLeaks have forced governments to admit that the real death toll of the wars was higher than had been suggested before, and that the wars weren't going as successfully as they had been portrayed. This information has sparked new discussions about the strategy to follow from that point onwards. Almost simultaneously, people have started calling WikiLeaks irresponsible, have started calling for them to be shut down. Julian Assange's reputation has been dealt a great blow - perhaps entirely through faults of his own, I don't know.
So yes. We need accurate information, not censored tripe, cooked-up propaganda, and inflammatory words. Yet, censorship, propaganda, and inflammatory words is what we have been getting from governments. Remember: the first casualty of war is truth.
Has WikiLeaks gone too far with their releases? Perhaps they have. But they have certainly shown us evidence that governments were trying to hide from us. Evidence that might well have led us to think differently about the wars we have entered into. I am glad someone is doing that job. And if our governments had been honest and truthful, whatever WikiLeaks could have been released would have been a boring rehash of what we would have known already. So perhaps WikiLeaks have gone too far, but, the way I see it, they have also done good and important work. Precisely _because_ we need accurate information.
``these are not ordinary trolls talking and raving on the internet. these are actual countries, which have various departments, including intelligence agencies which may act in direction of the desire of their government.''
Oh, I am well aware of that. Obviously random trolls on the Internet aren't the same as official diplomats talking to government officials.
The only point I tried to make is that I can still see why such talks could be less harmful when kept secret than if they became public. Of course, if the result is actual war, then it doesn't matter a lot if it was the result of secret or public talks. But war is not a certain outcome in either case. Just because country A asks country B to go to war with country C doesn't mean country B will do so.
If country B decides not to go to war with country C, that could well be the end of the story. If the talks are secret, we can all go to sleep quietly. But if the talks are published, then there may be violent reactions, even if country B had decided not to go to war. I feel this risk is greatly amplified if the talks are published.
Well, to be fair, just because someone advocates starting a war does not mean that war will actually be started. I am not at all in favor of war, but I can see how calling for a war _in secret_ is less destabilizing than calling for that same war in public. So the position that "war is more destabilizing than calling for a war" and the position that "publishing a call for war is destabilizing" are not mutually exclusive.
``US ambassadors in other capitals were instructed to brief their hosts in advance of the release of unflattering pen-portraits or nakedly frank accounts of transactions with the US which they had thought would be kept quiet. Washington now faces a difficult task in convincing contacts around the world that any future conversations will remain confidential.''
And here I thought that last sentence would end "that any future conversations will be more civil". At least, I have always thought that saying "unflattering" things behind people's backs isn't the way to behave. If the conversations between the US and its contacts are of such "unflattering" nature that they give rise to diplomatic crises when uncovered, then perhaps the US should have trained their employees and contact to not behave that way.
I understand the anger at WikiLeaks, and I understand that it is not just about the unflattering communications. But still, on this one point, I think that if you don't want to take the heat for your missteps, the best way would be not to make them. So, rather than assuring contacts that, in future, this stuff will stay confidential, I would think that the right response would be to convince your contacts that, in future, you will work to keep things civil and decent.
Who will win control of the Web? I will. In fact, I already have it, and have had it since some time in the 1990s. And if some entity somehow takes that control away from me, I or one of my many fellow producers of web content will create a new Web, and we will use that.
I hear people praise Visual Studio a lot, but, having used it on a few projects myself, I am not impressed by it. Granted, if you are coding for Microsoft platforms like.NET, it may be your best choice since there isn't a whole lot of competition there. But as development environments go, I wouldn't call it great. It's not horrible, either, but it does have enough bloat, bugs, and missing features to make me rather not work with it.
Add to that that, to use VS professionally, you actually need to pay - for VS and for Windows, and the combination of some things that work in newer versions not working in older versions, and vice versa, and my conclusion is that Visual Studio is a waste of money. You pay, but what you get is not better than what you could have gotten for free - unless you're locked into some Microsoft technology that isn't supported anywhere else.
All this in my opinion, of course, just like what you said is your opinion. If you continue to enjoy VS, that's great! I just wanted to throw this out there to point out that not everybody things Visual Studio is great.
``As Seymour Cray said: fast CPUs are easy, it's making fast/systems/ that's hard. You need good I/O to keep the CPUs fed.''
Absolutely. In almost everything I do that is slow, either I/O is the bottleneck, or the software is inefficient (i.e. the same operations could be implemented with much faster algorithms). This is why I rarely buy the fastest CPU I can get: the CPU isn't the bottleneck, so it's better to save there and spend where it's needed.
As far as I know, Linux currently supports up to 256 CPUs. I assume that means logical CPUs, so that, for example, this would support one CPU with 256 cores, or one CPU with 128 cores with two CPU threads per core, etc.
This story makes me curious: how has JavaScript implementation speed improved over time? I see a lot of benchmarks comparing recent versions of browsers, but does anyone have a comparison against, say, Firefox 1.0? Also, how do current JavaScript implementations stack up against current implementations of other languages, such as C, Lua, or Python?
``The number might seem small at first, especially compared to other distros. The main difference, though, is that those packages aren't just nice addons to the base system but rather supported 24/7 and kept updated for quite a few years from now.''
Which also goes for Debian. Of course, RHEL is tailored for enterprise environments, whereas Debian is general-purpose. And none of those things say anything about which one is better. I have better experiences with Debian, but I think they are both fine operating systems.
While I feel for those whose otherwise great games get broken by having parts of or close to the main storyline cut out and charged extra for, there is also an upside to this. The more the main publishing houses go this route, the more attractive alternative games become by comparison.
There are several games out there that have interesting ideas in them, but can't compete with the mainstream titles' multimedia splendor. If the DLC SNAFU brings more success to these alternative games, I'll count that as a plus. Heck, we may even get more good open source games.
``Well, there are a few alternatives. If you store your passwords in an insecure manner (postit under the keyboard, your secretary etc...) then you have allready lost.''
Actually, no. If it's a strong password, it still protects against anyone who can't access the password (e.g. can't get to the post-it, doesn't get given it by the secretary, etc). That protects against the untargetted dictionary attacks that float around the 'net, which is actually the kind of attack I see most.
``If you send your passwords in clear text over the network and worry about sniffing you don't care about the security.''
Sniffing is, at the same time, more of a risk and less of a risk than people realize. A lot of people don't realize there is any risk at all, or would know there is a risk if you asked them, but otherwise don't stop to think about it. On the other end of the spectrum, there are people who think that any cleartext transmission can easily be sniffed by any interested party. The truth is that transmissions over wired networks are mostly unicast these days, so any intercepting party would have to be on the transmission path to be able to sniff. WLAN is a wholly different matter, as it is often possible for anyone on the network to intercept all traffic within radio range. But even in that case, you are usually talking about tens of nodes, rather than the whole Internet. Of course, encryption is still a good idea and should be used, unless there is a good reason not to do so.
``In the end, passwords are simple security mechanisms for discuraging causual abuse of systems.''
I agree, and that's why I'm for the use of strong passwords. If you have too many to remember, memorize just one and put the rest in a password file that you protect using the password you memorized. It's easy and secure. If even that doesn't work (for example, you move around a lot and can't always access your password file), find a different solution for the problematic cases. If you have to compromise, writing down a hint, part of the password, or even the full password isn't that bad: you still keep out people who don't have physical access to the note. Weak passwords are the greater problem: they can be guessed by attackers, or easily remembered by lots of people who can't necessarily all be trusted all the time.
``The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.''
I am glad he figured that out. Unix contains a lot of useful commands and functions. Every programmer would do well to learn them, so they can use them when needed.
What also helps a lot is knowing your programming language well. By that, I mean not just the standard library, but also the fundamentals of the language. Know how things fit together, which things are efficient and which things are costly, and how to design good APIs in that language. Better yet: know this for multiple languages - different languages for different tasks. It's easy to learn a new programming language when you already know how to program, and doing so will provide you with new insights, so go ahead and learn another language.
It is also useful to know tools and libraries that aren't a standard part of the operating system. Of course, there are very many of those and learning them all might be a bit much. Still, knowing a handful and having heard of others can help a lot. No need to write, debug, and maintain your own code for parsing CSV, XML, YAML, or whatever the file format of the season is. Beware of bugs and misfeatures, though. Many libraries, even commonly used ones, contain bugs. Many libraries also contain choices that may or may not be a good idea for what you want to do.
All in all, you can get a long way by just knowing what other people have already done for you. Thanks to free software, you can often use this work in your projects. The world wide web has made it fairly easy to find things that you may use. A lot of software can be made by taking a bunch of libraries and writing some code to stitch it together and make it do stuff. Or, as Mr. Dziuba found out, by mixing together some command-line tools. I am glad he is discovering the strengths of Unix and getting excited enough about them to tell the world about it.
Stitching things together from existing components is not all there is to programming, however. You can go a long way doing just that, and many people make a living that way, but there are some things which are best solved or can only be solved by thinking hard and coming up with some clever code to do exactly the right thing. And somebody needs to write those tools and libraries, too. Compared to putting some existing components together, it's hard work for small results, but I find this to be the most rewarding part of programming. You're really coming up with something new here, making something clever and useful that wasn't available before.
Honestly, I would be scared if a chat bot managed to get all these right. Although I don't rightly know why. I believe it's possible. Then why would I be scared?
Slashdot Mirror
It just goes to show that the reason that IE got to have so much dominance was not because it was bundled with the operating system, but that for far too long it had no real competition.
I rather think that it means you're looking at the data too late. Of course MSIE was the dominant browser when it didn't have any real competition, but that was after the competition had been killed off. Before that, there was healthy competition between Microsoft Internet Explorer and Netscape Navigator.
Although it is impossible to say for certain, many believe that MSIE came to have ~90% market share through a combination of being bundled with the operating system and having become good enough that it wasn't worth the trouble to get a different browser. Netscape went under and it would take years for Mozilla to produce something that people would actually prefer over MSIE, but all this time, there had been Opera, who have made a very impressive browser at least since their 3.x days. Why is it that they never managed to sway a large percentage of users? Could it be because Opera, other than Netscape and IE, was never included on ISPs installation disks, included with shareware magazine's distributions, or bundled with operating systems on large scale?
Recent history also tells some interesting stories. At some point, Microsoft apparently got worried enough about the competition on the browser front that they created an Internet Explorer team again. Yes, they had actually disbanded the IE team after the release of IE 6. So what did the competition have to do to get back in the game? Well, take a look at Firefox, Opera and Safari from around Firefox's 1.0 release, and you will find that they are light years ahead of MSIE 6 - which really isn't all that different from MSIE 5.5. Let's also not forget that Firefox had a stable base on *nix, and Safari on Mac OS X, so they would continue to be improved regardless of adoption by Windows users.
Does bundling a browser with the operating system (or ISP service) give that browser a huge advantage over the competition? I think it is clear that it does.
``maybe this should be taken as a sign that the problem NX solves needs a different solution. Like, oh I don't know... maybe revising the X windows protocol so it doesn't suck so hard it has its own event horizon?''
Yeah, maybe. Of course, this has been tried many times before, and not with much success, I believe.
The truth to the matter is that the X protocol is actually pretty good. It's the software that implements it that could be better. That at least used to be true of both servers and Xlib (range checks, anyone?), as well as clients. If you think X is slow, it is almost certainly because you are using a client that causes a lot of network round trips and waits for them. There is absolutely nothing in the X protocol that forces you to do so. But if you do so, then, yes, your app will be very slow over a moderate-latency link.
Indeed, usually, the slowness in X is caused by network latency (the exception being if you are rendering a lot of pixels, e.g. for movies). Moreover, the slowness is often not inherent in the X protocol, but rather caused by how an application uses it. Some X clients are amazingly fast, even over moderate latency links.
This is also why you often get a more responsive UI by using something that just pushes pixel data, like VNC, instead of X. They work faster, even though they are less efficient in terms of amount of network traffic. It's not the throughput, it's the latency.
You could actually do the same thing with X: just render your whole app to an XImage, then render that to the server. This will be faster than synchronously performing all your drawing operations over the network, if you do lots of drawing operations. On the other hand, if you have lots of images that you tend to reuse, store them on the server as XPixmaps, and then you can render them faster than you could by pushing the pixels each time. X offers you this choice, and when used well, can actually be _faster_ than other technologies over any kind of network. The only thing I haven't found is a way to compress pixel data, but perhaps that is just because I haven't looked hard enough.
Perhaps I don't remember it right, but in my recollection, NoMachine has always been a bit possessive with their (definitely impressive) technology. To the point that lesser alternatives have continued to be used and even developed.
"NoMachine has sneakily revealed..."
That's quite remarkable.
Using NAT as a security measure is like burning bridges.
Sure, it keeps the enemy from using the bridges to get into your city.
It also keeps friendly and useful visitors from doing so.
And your enemy will just enter your city by boat.
I haven't been following the events here so far, and a little searching yielded a lot of words that I am not familiar with and not a lot of insight. Could someone explain what the issue is here?
As far as I have been able to tell, the focus is on the licensing terms for the TCK, and the TCK is a test suite for existing and proposed Java standards. Oracle owns the rights to TCK and will not license it to the Apache Software Foundation under terms that the ASF will agree to.
Assuming that I have that right, so what? It's Oracle's software; they can choose to license it as they see fit, right? I _thought_ that passing the TCK's tests was necessary for being allowed to call your stuff "Java", but searching the web, I didn't find anything that supported that. So, correct me if I'm wrong, but as far as I can see, ASF is not being restricted in what they can and can't do.
What am I missing here?
Another point of view is that WikiLeaks had best inspect what they release, and do their best to prevent putting lives at risk, especially those of innocent bystanders and those who are working for the greater good. They're damned if they do and damned if they don't: if they take their time to filter and redact, they are delaying and possibly twisting the truth, but if they don't do that, they are irresponsible.
``I'm certain more details will come out as people have more time to go through these documents. But so far what I've found most surprising is how unsurprising these documents are. So the US is spying. Big fucking deal, everybody spies. This isn't news.''
That's what I would think, too. So what _is_ the big deal here? Obviously, there is a big deal, otherwise governments wouldn't get so upset over it.
``Our governments need accurate information, not self-censored tripe.''
Yes, I very much agree. And so do our populations. And in neither case are insults and offensive wording very helpful.
So there are several things here. First of all, having a good view of the whole picture is crucial to making the right decisions. Secondly, rousing emotions and withholding part of the information impedes getting a good view of the whole picture.
What I have seen from the US government in the last, say, 10 years, has been quite a bit of playing on emotions, withholding information, and even outright lies.
Two wars were started. Osama Bin Laden has not been caught, and terrorists are still active. No weapons of mass destruction have been found in Iraq that I am aware of. The USA declared victory in Iraq, and I think most of the bloodshed has actually come after that point.
The real number of casualties, the crimes against humanity, the existence of certain prisons and the interrogation methods being used there have all been swept under the rug by the USA and its allies.
WikiLeaks has been showing the world what has really been going on. The fact that they can _shock_ the world by releasing a video of military personnel shooting civilians is telling to me. It looked like a tragic accident to me. This is what war is really like. Such accidents happen.
Other releases by WikiLeaks have forced governments to admit that the real death toll of the wars was higher than had been suggested before, and that the wars weren't going as successfully as they had been portrayed. This information has sparked new discussions about the strategy to follow from that point onwards. Almost simultaneously, people have started calling WikiLeaks irresponsible, have started calling for them to be shut down. Julian Assange's reputation has been dealt a great blow - perhaps entirely through faults of his own, I don't know.
So yes. We need accurate information, not censored tripe, cooked-up propaganda, and inflammatory words. Yet, censorship, propaganda, and inflammatory words is what we have been getting from governments. Remember: the first casualty of war is truth.
Has WikiLeaks gone too far with their releases? Perhaps they have. But they have certainly shown us evidence that governments were trying to hide from us. Evidence that might well have led us to think differently about the wars we have entered into. I am glad someone is doing that job. And if our governments had been honest and truthful, whatever WikiLeaks could have been released would have been a boring rehash of what we would have known already. So perhaps WikiLeaks have gone too far, but, the way I see it, they have also done good and important work. Precisely _because_ we need accurate information.
``these are not ordinary trolls talking and raving on the internet. these are actual countries, which have various departments, including intelligence agencies which may act in direction of the desire of their government.''
Oh, I am well aware of that. Obviously random trolls on the Internet aren't the same as official diplomats talking to government officials.
The only point I tried to make is that I can still see why such talks could be less harmful when kept secret than if they became public. Of course, if the result is actual war, then it doesn't matter a lot if it was the result of secret or public talks. But war is not a certain outcome in either case. Just because country A asks country B to go to war with country C doesn't mean country B will do so.
If country B decides not to go to war with country C, that could well be the end of the story. If the talks are secret, we can all go to sleep quietly. But if the talks are published, then there may be violent reactions, even if country B had decided not to go to war. I feel this risk is greatly amplified if the talks are published.
I hope that makes my message clear. :-)
Well, to be fair, just because someone advocates starting a war does not mean that war will actually be started. I am not at all in favor of war, but I can see how calling for a war _in secret_ is less destabilizing than calling for that same war in public. So the position that "war is more destabilizing than calling for a war" and the position that "publishing a call for war is destabilizing" are not mutually exclusive.
``US ambassadors in other capitals were instructed to brief their hosts in advance of the release of unflattering pen-portraits or nakedly frank accounts of transactions with the US which they had thought would be kept quiet. Washington now faces a difficult task in convincing contacts around the world that any future conversations will remain confidential.''
And here I thought that last sentence would end "that any future conversations will be more civil". At least, I have always thought that saying "unflattering" things behind people's backs isn't the way to behave. If the conversations between the US and its contacts are of such "unflattering" nature that they give rise to diplomatic crises when uncovered, then perhaps the US should have trained their employees and contact to not behave that way.
I understand the anger at WikiLeaks, and I understand that it is not just about the unflattering communications. But still, on this one point, I think that if you don't want to take the heat for your missteps, the best way would be not to make them. So, rather than assuring contacts that, in future, this stuff will stay confidential, I would think that the right response would be to convince your contacts that, in future, you will work to keep things civil and decent.
Who will win control of the Web? I will. In fact, I already have it, and have had it since some time in the 1990s. And if some entity somehow takes that control away from me, I or one of my many fellow producers of web content will create a new Web, and we will use that.
``The Visual Studio IDE is great''
I hear people praise Visual Studio a lot, but, having used it on a few projects myself, I am not impressed by it. Granted, if you are coding for Microsoft platforms like .NET, it may be your best choice since there isn't a whole lot of competition there. But as development environments go, I wouldn't call it great. It's not horrible, either, but it does have enough bloat, bugs, and missing features to make me rather not work with it.
Add to that that, to use VS professionally, you actually need to pay - for VS and for Windows, and the combination of some things that work in newer versions not working in older versions, and vice versa, and my conclusion is that Visual Studio is a waste of money. You pay, but what you get is not better than what you could have gotten for free - unless you're locked into some Microsoft technology that isn't supported anywhere else.
All this in my opinion, of course, just like what you said is your opinion. If you continue to enjoy VS, that's great! I just wanted to throw this out there to point out that not everybody things Visual Studio is great.
``As Seymour Cray said: fast CPUs are easy, it's making fast /systems/ that's hard. You need good I/O to keep the CPUs fed.''
Absolutely. In almost everything I do that is slow, either I/O is the bottleneck, or the software is inefficient (i.e. the same operations could be implemented with much faster algorithms). This is why I rarely buy the fastest CPU I can get: the CPU isn't the bottleneck, so it's better to save there and spend where it's needed.
Running Linux on a 48-core system is boring, because it has already been run on a 64-core system in 2007 (at the time, Tilera said they would be up to 1000 cores in 2014; they're up to 100 cores per CPU now).
As far as I know, Linux currently supports up to 256 CPUs. I assume that means logical CPUs, so that, for example, this would support one CPU with 256 cores, or one CPU with 128 cores with two CPU threads per core, etc.
"In a move sure to have transparency activists salivating, the UK government has some 195,000 lines of data detailing its financial outgoings."
Has what? I hope they didn't accidentally it!
How does the sound and image quality of the WebM videos compare to the versions in other formats?
This story makes me curious: how has JavaScript implementation speed improved over time? I see a lot of benchmarks comparing recent versions of browsers, but does anyone have a comparison against, say, Firefox 1.0? Also, how do current JavaScript implementations stack up against current implementations of other languages, such as C, Lua, or Python?
``The number might seem small at first, especially compared to other distros. The main difference, though, is that those packages aren't just nice addons to the base system but rather supported 24/7 and kept updated for quite a few years from now.''
Which also goes for Debian. Of course, RHEL is tailored for enterprise environments, whereas Debian is general-purpose. And none of those things say anything about which one is better. I have better experiences with Debian, but I think they are both fine operating systems.
While I feel for those whose otherwise great games get broken by having parts of or close to the main storyline cut out and charged extra for, there is also an upside to this. The more the main publishing houses go this route, the more attractive alternative games become by comparison.
There are several games out there that have interesting ideas in them, but can't compete with the mainstream titles' multimedia splendor. If the DLC SNAFU brings more success to these alternative games, I'll count that as a plus. Heck, we may even get more good open source games.
``Well, there are a few alternatives. If you store your passwords in an insecure manner (postit under the keyboard, your secretary etc...) then you have allready lost.''
Actually, no. If it's a strong password, it still protects against anyone who can't access the password (e.g. can't get to the post-it, doesn't get given it by the secretary, etc). That protects against the untargetted dictionary attacks that float around the 'net, which is actually the kind of attack I see most.
``If you send your passwords in clear text over the network and worry about sniffing you don't care about the security.''
Sniffing is, at the same time, more of a risk and less of a risk than people realize. A lot of people don't realize there is any risk at all, or would know there is a risk if you asked them, but otherwise don't stop to think about it. On the other end of the spectrum, there are people who think that any cleartext transmission can easily be sniffed by any interested party. The truth is that transmissions over wired networks are mostly unicast these days, so any intercepting party would have to be on the transmission path to be able to sniff. WLAN is a wholly different matter, as it is often possible for anyone on the network to intercept all traffic within radio range. But even in that case, you are usually talking about tens of nodes, rather than the whole Internet. Of course, encryption is still a good idea and should be used, unless there is a good reason not to do so.
``In the end, passwords are simple security mechanisms for discuraging causual abuse of systems.''
I agree, and that's why I'm for the use of strong passwords. If you have too many to remember, memorize just one and put the rest in a password file that you protect using the password you memorized. It's easy and secure. If even that doesn't work (for example, you move around a lot and can't always access your password file), find a different solution for the problematic cases. If you have to compromise, writing down a hint, part of the password, or even the full password isn't that bad: you still keep out people who don't have physical access to the note. Weak passwords are the greater problem: they can be guessed by attackers, or easily remembered by lots of people who can't necessarily all be trusted all the time.
``The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.''
I am glad he figured that out. Unix contains a lot of useful commands and functions. Every programmer would do well to learn them, so they can use them when needed.
What also helps a lot is knowing your programming language well. By that, I mean not just the standard library, but also the fundamentals of the language. Know how things fit together, which things are efficient and which things are costly, and how to design good APIs in that language. Better yet: know this for multiple languages - different languages for different tasks. It's easy to learn a new programming language when you already know how to program, and doing so will provide you with new insights, so go ahead and learn another language.
It is also useful to know tools and libraries that aren't a standard part of the operating system. Of course, there are very many of those and learning them all might be a bit much. Still, knowing a handful and having heard of others can help a lot. No need to write, debug, and maintain your own code for parsing CSV, XML, YAML, or whatever the file format of the season is. Beware of bugs and misfeatures, though. Many libraries, even commonly used ones, contain bugs. Many libraries also contain choices that may or may not be a good idea for what you want to do.
All in all, you can get a long way by just knowing what other people have already done for you. Thanks to free software, you can often use this work in your projects. The world wide web has made it fairly easy to find things that you may use. A lot of software can be made by taking a bunch of libraries and writing some code to stitch it together and make it do stuff. Or, as Mr. Dziuba found out, by mixing together some command-line tools. I am glad he is discovering the strengths of Unix and getting excited enough about them to tell the world about it.
Stitching things together from existing components is not all there is to programming, however. You can go a long way doing just that, and many people make a living that way, but there are some things which are best solved or can only be solved by thinking hard and coming up with some clever code to do exactly the right thing. And somebody needs to write those tools and libraries, too. Compared to putting some existing components together, it's hard work for small results, but I find this to be the most rewarding part of programming. You're really coming up with something new here, making something clever and useful that wasn't available before.
Honestly, I would be scared if a chat bot managed to get all these right. Although I don't rightly know why. I believe it's possible. Then why would I be scared?