``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.

Nice.

I'm in charge of PCI Compliance where I work, so I totally feel your pain.

Hopefully their volume is low enough that they can just do a SAQ?

``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.

Only in the US because the right is so far to the right already, that a just barely right of center opposition is considered "left".

``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?

Congratulations to skwilcox for making such a great chat bot! I think this is really fascinating. Keep it up!

``I have made biodiesel myself(methanol/lye recipe) and our diesel generator loved it at 80Bio/20Die''

Well done!