"the four men will have to pay $3,6 million in compensation for lost sales to 17 media companies."
It strikes me that this is less than they could have gotten by setting up their own online distribution system. Subtract all the money they have spent fighting The Pirate Bay, including what they spent on this lawsuit. How much is left?
What if, instead of trying to fight it, the media companies had gone with the flow? They could have set up their own service. It could offer the movies and other media, perfectly legal and in good quality. This would make it more convenient than what The Pirate Bay offers: bootleg copies of varying quality, which may or may not be in the language you want, may or may not have working subtitles, may or may not contain malware, etc. Such a service need not even cost the user more: it could be ad-supported, like television.
I really wonder why the media companies haven't created such a service. Unless, perhaps, piracy isn't really costing them a lot of sales, and going after large-scale piracy operations is just a way to make some extra money.
I thought that would put a whole different spin on the high price tag of the Tesla cars, but then I did the math and was disappointed.
I live in the Netherlands, which has about the highest gas prices in the world. A liter of gasoline currently costs about 1.30 euros (that's about 6.6 USD per US gallon). A not-very-efficient gasoline car might use about 8 liters per 100 km, so that works out to about 1.30 * 8 / 100 = 0.104 cents per km.
Taking one data point, I drive about 30000 km a year. If I drove the above not-so-efficient car, I could save up to 0.104 euros per km, or 3120 euros (about 4200 USD at current exchange rates) per year. Of course, I would only achieve that if charging the Roadster were free, so actual savings are going to be less. And it's not a lot of money, compared to the Roadster's price tag.
Not that this invalidates the fact that Tesla makes some really cool cars. I'm very curious how the Model S will turn out.
``I've read complaints that reviews of new Linux distros often focus too much on the installation process;''
It's not that they focus too much on the installation process, it is that they pay too little attention to the rest. Many of these reviews can be characterized as "the installation process such and such, this and this were my experiences with support for my hardware, and the GUI looks good".
What I want to know is what the everyday user experience is like. How the installation goes is important, but you're performing the installation because you want the installed system. So how well are the various packages integrated with the system? Which applications are available? What is the quality of the packaging? Are dependencies automatically resolved? What about uninstalling software? How responsive is the security team? Do you get timely security updates and do they break things? When you get non-security updates, how likely are they to break your existing configuration? Can you upgrade the whole system to the next release, and how well does this work? All things considered, how much time do you need to spend on maintenance to keep the system secure and working smoothly?
All these points are very important in determining choice of operating system. Alas, you only find them out after running the same system for an extended period of time and learning the ins and outs of it. Reviewers almost never take the time to do this, so the review pretty much stops after the installation is complete.
``Microsoft seems to understand that complications at installation time (dual booting? preserving an existing data partition?) can sour one's experience pretty thoroughly.''
I completely understand Microsoft's point that "upgrading from beta to release candidate" is not a scenario they have decided to support, and issuing a warning to the world that this might well break things horribly.
However, you seem to be suggesting that Microsoft understands the finer points of upgrading one OS to another and/or running multiple OSes alongside one another and are doing the right thing. I can't really agree with that. I've seen multi-boot the Microsoft way, and it's usually "do you want to boot this Microsoft OS or that Microsoft OS?". Other operating systems are completely ignored. And don't try mucking with the boot loader, or you may well get the "NTLDR is missing" error and be unable to boot Windows anymore. Maybe all this is intentional, but all I know for sure is that things are worlds better in the open source universe.
What is the point of simulating a slow, lossy network? Why, figuring out how your setup would behave if it were in a real slow, lossy network, of course!
I use tricks like this quite frequently when developing network software and network protocols. Especially when I'm working on my forward error correction protocol, because that is _intended_ for slow, lossy networks. Alas, my Ethernet is very fast and very reliable.;-)
A real open standard? As in, free for all to implement, without any encumberance?
Also, I have never gotten Gnash to really work. Newer versions at least get to the point where they do something on YouTube, but they eat 100% CPU and I get nowhere near a usable framerate. Not to knock the hard work of the developers, but Flash is nowhere near a universally usable standard.
On the other hand, many features can actually be added to Windows XP without Microsoft's help. I'm not sure it would be possible to replace the scheduler or the memory manager, but you can certainly add and/or replace applications, libraries, drivers, and user interface skins. I don't think, say, supporting the latest graphics cards, additional file systems, and a next generation Internet protocol would be impossible.
I don't know how the law works in Sweden, but, in the Netherlands, it's like this (disclaimer, IANAL, but I have read the laws):
1. The author of a work gains certain exclusive rights to it. This means that you, if you are not the author, may not do these things, unless you obtain permission from the rights holder.
2. There are other things you are allowed to do, even if you are not the rights holder.
3. Notably, if the work comes on a medium (for example, music that comes on a CD), unless the work is a computer program, you are allowed to make a copy for personal use, or have someone make a copy for you. You do not need to own the medium (e.g. you can borrow a CD from a friend and make a copy).
4. If the rights holder takes "technical measures" to prevent you from doing certain things, circumventing such technical measures is a criminal offense.
Taking this all together leads to a very interesting situation. Downloading a movie from the Internet counts as making a copy for personal use and is perfectly legal. Using DeCSS to decrypt a DVD that you bought so that you can watch it circumvents a technical measure and is, therefore, a crime.
I encourage everyone to play by the rules, and I also encourage everyone to know what the rules are.
I was just researching ECC memory and memory errors a few weeks ago. I am planning to build a computer with so much RAM that it can basically keep all my most frequently accessed files and programs in main memory, all the time. However, this made me seriously consider the reliability of RAM. I was pleasantly surprised that ECC RAM is quite easy to find and not that much more expensive than non-ECC RAM. However, figuring out which motherboards and/or CPUs support ECC RAM was so tedious that I gave up.
I have not been able to find any clear information about whether ECC support is purely a motherboard issue, purely a CPU issue, or a combination, for most kinds of CPU. My best guess is that if the CPU does not have an integrated memory controller (Intel CPUs and some AMD CPUs), ECC support is a motherboard issue, and if the CPU does have an integrated memory controller (many AMD CPUs), then ECC needs to be supported by both the CPU and the motherboard. In all cases, ECC needs to be supported by the RAM (although, in theory, this doesn't have to be the case).
With these somewhat shaky assumptions, I went to investigate what combination of 64-bit CPU and motherboard I could buy that would support at least 8 and preferably at least 16 GB of ECC RAM, preferably non-registered. As it turns out, whether a particular motherboard or CPU supports ECC memory is often not listed by sellers. Searching the web for this kind of information is difficult, because searching for "ECC" will give you many hits that are, in fact, "non-ECC" - which means that the component supports non-ECC memory, but doesn't mean it supports _only_ non-ECC memory.
All this really confused me. If it is so easy to find ECC-memory, it seems reasonable to assume there is a fairly strong demand for it. But if that is the case, why is it so difficult to find out which CPU/motherboard combinations support ECC? And, actually, why aren't we all using ECC memory nowadays? I would say that the probability of memory errors occurring must have increased with increased megabits per chip, both because there are more bits that can be flipped and because the energy needed to flip a bit is smaller. Given that, I would say memory reliability is a real issue. But it is hard to even find up to date statistics on this.
Now, I know all of my failures to find information can just be attributed to me not searching in the right way, but I really want to know the answers. So, any help and advice appreciated.
As for the computer I want to build:
- 64-bit CPU with virtualization extensions, preferably multi-core
- 8 or 16 GB of ECC RAM
- 80 or more GB solid state disk
- Video card with fast 3D using open-source drivers (this probably means AMD)
- I care about power consumption, especially when the system is idle
- Preferably no moving parts
I know this is ambitious, but everything besides figuring out if it will support ECC seems feasible.
My thoughts on the matter are this. While critical thinking should always be encouraged, there isn't time to look critically at every issue and get everybody convinced that it is a certain way. So you don't want schools to be forced to have all the discussions about every issue. At some point, you have to just teach that something is a certain way and get on with it.
At the same time, it is important that people understand some core principles. The truth is not what somebody says it is, it is what is actually out there. There are various methods of learning what is out there, each with their own advantages and disadvantages. It is important to know which things are certain and which things are not. So, here, you take a look at argumentation, fallacies, critical thinking, statistics, and the scientific method. Here, you go into detail on various theories that have been proposed and refuted. And here, you explain that what is taught in the rest of the programme is not the truth, but something that, to the best of our knowledge, has not been shown to be false. Or, as the case may be, a simplification that works well enough to be useful, even though we know the Real World is more complex.
This way, you teach both critical thinking and the rest of the programme, without having to get stuck in endless discussions at every turn.
``"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"
Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...''
Well? That doesn't make it any less of a renaissance. If anything, it makes it more like the renaissance. After all, that also started with the idea of "hey, let's go do something with all this great stuff we had a long time ago".
``If anyone hosts anything more important than their grocery list on someone else's servers, then they deserve the inevitable security breaches that will follow. The entire nature of Google Docs (hosting your data on someone else's servers) is a security concern.''
This is true, but that doesn't mean it's actually a bad idea. The thing you have to ask yourself as a decision maker is: how much control do I have over my own company's computers, how competent are my admins, etc. etc. Then you ask the same questions about a hosted service. And then you make your choice.
If you have competent admins who you trust, the best choice may be to keep everything inside your company. However, it may well be that you don't have and/or cannot afford the necessary hardware and admins. At some point on the spectrum, hosting your documents elsewhere becomes the better choice.
Remember, you never get absolute security. Your documents are at risk when you host them inside your company, and they are at risk when you host them outside your company. Like with all other risks, you have to account for this risk. Eventually, it becomes part of the cost-benefit analysis. And the cost-benefit analysis could swing either way: hosting internally or hosting externally.
Of course it's a bug. log10(1000) is 3, so truncating it should yield 3. Unless, of course, the specification very clearly states that operations are implemented using some kind of arithmetic that produces a different result. But, in that case, I don't want to use the software.
``We don't need another language run on what compiler people call a "naive interpreter".''
I agree. Languages like Ruby and Python are hard to beat on easy of use and programmer productivity. However, current implementations don't offer stellar performance. I think there is room for a language that allows both great programmer productivity and great performance, and the work I have been doing is all on languages that compile to efficient machine code. Besides that, I seek to integrate a number of other features, such as a syntax fit for interactive use (think Unix shell), strong checks (up to the point where you can statically prove that the program will not crash (barring failures in the underlying system)), and automatic concurrency.
While on the topic, I would like to ask a similar question. What places can people recommend for doing programming language research? I have a MSc in computer science, and I am thinking about getting back into academics after a few years of working. I have been studying and inventing programming languages as a hobby for a number of years now, and I am thinking that, perhaps, I could combine the two and do a PhD project related to programming languages. However, next time I go to university, I want the environment to be a bit more intellectually stimulating than what I have experienced so far. Since I am not tied to any specific location or even country, I have a vast number of universities I could potentially turn to. But which ones would be a good choice? Can anybody recommend some? Or perhaps I should turn to specific people, instead of universities.
``You know you can write trivial java programs without using an IDE such as Eclipse.''
Of course you can. But Java is one of those languages that really benefit from an IDE. The reason is that Java programs invariable contain a lot of boilerplate code. Since this code is repetitive and doesn't require a lot of thinking to write, writing it can easily be automated, which is what IDEs do. Other languages don't require as much boilerplate to begin with, and thus benefit less from an IDE.
``The time it takes to compile is meaningless. You only need to do it once.''
I disagree. You need to compile only once only if you get the program right the first time. This means it has to be bug free, feature complete, and never receive any updates. This may indeed work for trivial programs, but, in practical software development, it doesn't happen. You write your programs in a number of iterations, each adding some features or fixing some bugs, and then you test to see if it works as you intended. Compile time can be a significant part of this process.
``You don't have to recompile every time you run the application.''
Funny you should say that, because Java runtimes typically do exactly that. That is to say, compiling Java bytecode to native machine code. All in all, Java programs typically take quite some time to start, and take a couple of minutes to really get up to speed. This causes small, short, and linear (not a lot of loops or repetition) to underperform (e.g. you wouldn't want this behavior for Unix commands).
It's sad that it's so easy to come up with ways to save power, but so few places and people actually implement them. I even have a colleague who refuses to turn off his computer, because "a 100 W more or less doesn't matter in the grand scheme of things". He's right about that, of course, but what he and many others don't realize is that doing the little things can actually affect the grand scheme of things. I, for example, use less than half as much electricity as the average household around me, simply because I use energy-efficient products and turn off most things when I'm not using them. It's not a lot of trouble, but if everybody did it, we could easily halve the power consumed by households!
``Note: I'm not defending the Phoronix guys. As a previous poster pointed out, they are inherently bad at explaining the why things are slower and sometimes they are flat out wrong''
In that case, the best they can do is to stop talking about it and just stick to what they know. Knowing just what is faster and what is slower is useful by itself. It can be used as a starting point for investigating what exactly caused the speed-ups and slowdowns. If the Phoronix folks can't or don't want to do this investigation themselves, it's perfectly fine to leave it up to other people.
I don't understand. The attackers gained access to the database...through the backup servers? That leaves me with two questions:
1. Why were the backup servers accessible to the attacker? 2. Why was the database accessible from the backup servers?
It seems to me that the only way you need to access the backup servers is through some mechanism that allows you to transfer data to and from them. A single open port, which you need a password (or key) to use seems all that should be exposed. That shouldn't be too hard to secure.
It also seems to me that the backup server has no business accessing the database, and therefore shouldn't be able to access the database.
Unless, of course, the way the system works is that the backup server accesses the production server to retrieve the data from it. That doesn't seem the most obvious design to me, but it would at least explain why the backup server could access the database. Maybe that is a good reason not to design the system that way (on the other hand, it saves complexity on the production server, which is good). At any rate, it doesn't answer the first question, which is why the attackers were able to access the backup server.
My sympathy goes out to the WHT administrators. Good luck on recovering from this and figuring out what went wrong. I hope you will keep us posted, so that we can all learn from this incident.
``Or is it that none of the users here have any idea of physics!?''
I wouldn't go as far as to say "none of us", but I wouldn't be surprised if most people on Slashdot didn't know the ins and outs of cutting-edge particle physics. After all, Slashdot is mostly about computers, not particle physics. Given this, I find it commendable that people mostly seem to refrain from making claims about things they know nothing about. The Real World could use more of that.
Yes, I agree. I know it isn't a popular point of view, but filesystems are really databases. All the issues that apply to databases also apply to filesystems. And, as with databases, you can go a long way pretending the issues don't exist. And then get everything messed up when one of the issues does hit you.
The major difference between filesystems and databases is that, for databases, a lot of research has been done about making them efficent _and_ correct. For filesystems, a lot of work has been done on making them efficient. But, as this drama shows, not a lot of work has gone into making them efficent and _correct_. And I don't mean ext4 specifically, I mean the filesystem API itself.
What we are seeing here is basically a transaction. A file is truncated and some data are written to it. We want either both of these things to happen (commit), or neither (roll back). Now, we have two options. We can do this asynchronously, which gives good performance but no guarantee the result will be a desireable one. Or we can do it synchronously, giving good results but bad performance. And this is a simple case. Try to come up with transactions involving multiple files and you will see why the filesystem makes a very _poor_ database.
``For EXT4, if it crashes, you can get a zero-length file, with both the old and new data lost.''
Since you seem to know what you are talking about, I'm asking you. What is it that causes this data loss? Why does it happen with ext4, but not with other filesystems?
``3) The issue is not about saving data, but the atomicity of updates so that either the new data or the old data would be saved at all times.''
This is, indeed, the central issue. And it's an issue not just with filesystems, but with anything that involves concurrency or transactions (multiple things that belong together). And it's an issue that few programmers get right.
The problem is that things often appear to work if you've not done them right. As long as there is only one thread and everything that thread does is performed successfully, there isn't a problem. So the program works, let's ship it. But then, in some Real World situation, there are suddenly multiple threads and/or failing operations. This can lead to spectacular failures.
The question is, of course, who gets to bear the burden for fixing the problems. Personally, I think there is an opportunity here for programming language and library designers to create APIs that make it easier to do the right thing, and harder to do the wrong thing. But given a specific API, it's up to the programmer to use it correctly. That doesn't mean you can't complain about the API and demand better APIs, but it does mean you can't complain when something that implements the API (correctly) does not magically make your broken code do the right thing. (Not that I am claiming that is what happened in this case - I don't know enough about it to be able to judge that.)
``So, while I'm all for applications using fsync when it's really needed, the last thing I'd like to see every application on the planet sprinkling their code with fsync "just to be sure".''
In other words, there is no substitute for doing it right.
``Q: Is the certificate mismatch a security hazard?''
A: Common sense would suggest it wouldn't be in a big popup dialog labeled "WARNING" if it wasn't. ''
However, experience shows that many programs show you big scary warnings for things that aren't actually big and scary. And often for things that you actually want to do.
For an on-topic example: invalid SSL certificates. SSL provides encryption. Depending on how you use it, it also provides authentication. For authentication, you need a valid SSL certificate. Such a certificate basically states "Trusted party X says that this certificate was issued for yourbank.example.com". For this to work, you need two things: you need to trust the third party, and the party it was issued to needs to be the party you want to do business with. If any of these isn't the case, you are back to where you were without a certificate - except for one thing, you still have encryption.
Now, the funny thing is that when you use plain HTTP, you get no SSL at all, meaning no encryption and no authentication. When you use SSL with an invalid certificate, you get encryption, but no authentication. This is more secure. Yet, it will give you a big, scary warning, whereas using plain HTTP will not.
So, yes, the big scary warning is there for a reason. It means the party you are communicating with may not be who they claim to be. On the other hand, you don't usually get that assurance anyway. And, really, you don't get that assurance when using a valid SSL certificate, either. That only says the trusted party says so...but the trusted party could be wrong.
Personally, I believe they are all doing it wrong, and all in the same way. They all assume things about the programming languages that will target the VM, and build the VM to support the constructs they've assumed the language will use.
I am much more in favor of a language-agostic approach. In my own TurboVM, I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to implement languages on TurboVM. No need to work around the fact that you get objects and methods, garbage collection, dynamic typing, etc. when you don't want them - TurboVM gives what a real machine would give you, without any bias towards specific programming languages.
Slashdot Mirror
"the four men will have to pay $3,6 million in compensation for lost sales to 17 media companies."
It strikes me that this is less than they could have gotten by setting up their own online distribution system. Subtract all the money they have spent fighting The Pirate Bay, including what they spent on this lawsuit. How much is left?
What if, instead of trying to fight it, the media companies had gone with the flow? They could have set up their own service. It could offer the movies and other media, perfectly legal and in good quality. This would make it more convenient than what The Pirate Bay offers: bootleg copies of varying quality, which may or may not be in the language you want, may or may not have working subtitles, may or may not contain malware, etc. Such a service need not even cost the user more: it could be ad-supported, like television.
I really wonder why the media companies haven't created such a service. Unless, perhaps, piracy isn't really costing them a lot of sales, and going after large-scale piracy operations is just a way to make some extra money.
I thought that would put a whole different spin on the high price tag of the Tesla cars, but then I did the math and was disappointed.
I live in the Netherlands, which has about the highest gas prices in the world. A liter of gasoline currently costs about 1.30 euros (that's about 6.6 USD per US gallon). A not-very-efficient gasoline car might use about 8 liters per 100 km, so that works out to about 1.30 * 8 / 100 = 0.104 cents per km.
Taking one data point, I drive about 30000 km a year. If I drove the above not-so-efficient car, I could save up to 0.104 euros per km, or 3120 euros (about 4200 USD at current exchange rates) per year. Of course, I would only achieve that if charging the Roadster were free, so actual savings are going to be less. And it's not a lot of money, compared to the Roadster's price tag.
Not that this invalidates the fact that Tesla makes some really cool cars. I'm very curious how the Model S will turn out.
``I've read complaints that reviews of new Linux distros often focus too much on the installation process;''
It's not that they focus too much on the installation process, it is that they pay too little attention to the rest. Many of these reviews can be characterized as "the installation process such and such, this and this were my experiences with support for my hardware, and the GUI looks good".
What I want to know is what the everyday user experience is like. How the installation goes is important, but you're performing the installation because you want the installed system. So how well are the various packages integrated with the system? Which applications are available? What is the quality of the packaging? Are dependencies automatically resolved? What about uninstalling software? How responsive is the security team? Do you get timely security updates and do they break things? When you get non-security updates, how likely are they to break your existing configuration? Can you upgrade the whole system to the next release, and how well does this work? All things considered, how much time do you need to spend on maintenance to keep the system secure and working smoothly?
All these points are very important in determining choice of operating system. Alas, you only find them out after running the same system for an extended period of time and learning the ins and outs of it. Reviewers almost never take the time to do this, so the review pretty much stops after the installation is complete.
``Microsoft seems to understand that complications at installation time (dual booting? preserving an existing data partition?) can sour one's experience pretty thoroughly.''
I completely understand Microsoft's point that "upgrading from beta to release candidate" is not a scenario they have decided to support, and issuing a warning to the world that this might well break things horribly.
However, you seem to be suggesting that Microsoft understands the finer points of upgrading one OS to another and/or running multiple OSes alongside one another and are doing the right thing. I can't really agree with that. I've seen multi-boot the Microsoft way, and it's usually "do you want to boot this Microsoft OS or that Microsoft OS?". Other operating systems are completely ignored. And don't try mucking with the boot loader, or you may well get the "NTLDR is missing" error and be unable to boot Windows anymore. Maybe all this is intentional, but all I know for sure is that things are worlds better in the open source universe.
``What is the point of doing this?''
What is the point of simulating a slow, lossy network? Why, figuring out how your setup would behave if it were in a real slow, lossy network, of course!
I use tricks like this quite frequently when developing network software and network protocols. Especially when I'm working on my forward error correction protocol, because that is _intended_ for slow, lossy networks. Alas, my Ethernet is very fast and very reliable. ;-)
``Flash is actually an open standard.''
A real open standard? As in, free for all to implement, without any encumberance?
Also, I have never gotten Gnash to really work. Newer versions at least get to the point where they do something on YouTube, but they eat 100% CPU and I get nowhere near a usable framerate. Not to knock the hard work of the developers, but Flash is nowhere near a universally usable standard.
``Features are not only "bling bling".''
On the other hand, many features can actually be added to Windows XP without Microsoft's help. I'm not sure it would be possible to replace the scheduler or the memory manager, but you can certainly add and/or replace applications, libraries, drivers, and user interface skins. I don't think, say, supporting the latest graphics cards, additional file systems, and a next generation Internet protocol would be impossible.
I don't know how the law works in Sweden, but, in the Netherlands, it's like this (disclaimer, IANAL, but I have read the laws):
1. The author of a work gains certain exclusive rights to it. This means that you, if you are not the author, may not do these things, unless you obtain permission from the rights holder.
2. There are other things you are allowed to do, even if you are not the rights holder.
3. Notably, if the work comes on a medium (for example, music that comes on a CD), unless the work is a computer program, you are allowed to make a copy for personal use, or have someone make a copy for you. You do not need to own the medium (e.g. you can borrow a CD from a friend and make a copy).
4. If the rights holder takes "technical measures" to prevent you from doing certain things, circumventing such technical measures is a criminal offense.
Taking this all together leads to a very interesting situation. Downloading a movie from the Internet counts as making a copy for personal use and is perfectly legal. Using DeCSS to decrypt a DVD that you bought so that you can watch it circumvents a technical measure and is, therefore, a crime.
I encourage everyone to play by the rules, and I also encourage everyone to know what the rules are.
I was just researching ECC memory and memory errors a few weeks ago. I am planning to build a computer with so much RAM that it can basically keep all my most frequently accessed files and programs in main memory, all the time. However, this made me seriously consider the reliability of RAM. I was pleasantly surprised that ECC RAM is quite easy to find and not that much more expensive than non-ECC RAM. However, figuring out which motherboards and/or CPUs support ECC RAM was so tedious that I gave up.
I have not been able to find any clear information about whether ECC support is purely a motherboard issue, purely a CPU issue, or a combination, for most kinds of CPU. My best guess is that if the CPU does not have an integrated memory controller (Intel CPUs and some AMD CPUs), ECC support is a motherboard issue, and if the CPU does have an integrated memory controller (many AMD CPUs), then ECC needs to be supported by both the CPU and the motherboard. In all cases, ECC needs to be supported by the RAM (although, in theory, this doesn't have to be the case).
With these somewhat shaky assumptions, I went to investigate what combination of 64-bit CPU and motherboard I could buy that would support at least 8 and preferably at least 16 GB of ECC RAM, preferably non-registered. As it turns out, whether a particular motherboard or CPU supports ECC memory is often not listed by sellers. Searching the web for this kind of information is difficult, because searching for "ECC" will give you many hits that are, in fact, "non-ECC" - which means that the component supports non-ECC memory, but doesn't mean it supports _only_ non-ECC memory.
All this really confused me. If it is so easy to find ECC-memory, it seems reasonable to assume there is a fairly strong demand for it. But if that is the case, why is it so difficult to find out which CPU/motherboard combinations support ECC? And, actually, why aren't we all using ECC memory nowadays? I would say that the probability of memory errors occurring must have increased with increased megabits per chip, both because there are more bits that can be flipped and because the energy needed to flip a bit is smaller. Given that, I would say memory reliability is a real issue. But it is hard to even find up to date statistics on this.
Now, I know all of my failures to find information can just be attributed to me not searching in the right way, but I really want to know the answers. So, any help and advice appreciated.
As for the computer I want to build:
- 64-bit CPU with virtualization extensions, preferably multi-core
- 8 or 16 GB of ECC RAM
- 80 or more GB solid state disk
- Video card with fast 3D using open-source drivers (this probably means AMD)
- I care about power consumption, especially when the system is idle
- Preferably no moving parts
I know this is ambitious, but everything besides figuring out if it will support ECC seems feasible.
My thoughts on the matter are this. While critical thinking should always be encouraged, there isn't time to look critically at every issue and get everybody convinced that it is a certain way. So you don't want schools to be forced to have all the discussions about every issue. At some point, you have to just teach that something is a certain way and get on with it.
At the same time, it is important that people understand some core principles. The truth is not what somebody says it is, it is what is actually out there. There are various methods of learning what is out there, each with their own advantages and disadvantages. It is important to know which things are certain and which things are not. So, here, you take a look at argumentation, fallacies, critical thinking, statistics, and the scientific method. Here, you go into detail on various theories that have been proposed and refuted. And here, you explain that what is taught in the rest of the programme is not the truth, but something that, to the best of our knowledge, has not been shown to be false. Or, as the case may be, a simplification that works well enough to be useful, even though we know the Real World is more complex.
This way, you teach both critical thinking and the rest of the programme, without having to get stuck in endless discussions at every turn.
``"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"
Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...''
Well? That doesn't make it any less of a renaissance. If anything, it makes it more like the renaissance. After all, that also started with the idea of "hey, let's go do something with all this great stuff we had a long time ago".
``If anyone hosts anything more important than their grocery list on someone else's servers, then they deserve the inevitable security breaches that will follow. The entire nature of Google Docs (hosting your data on someone else's servers) is a security concern.''
This is true, but that doesn't mean it's actually a bad idea. The thing you have to ask yourself as a decision maker is: how much control do I have over my own company's computers, how competent are my admins, etc. etc. Then you ask the same questions about a hosted service. And then you make your choice.
If you have competent admins who you trust, the best choice may be to keep everything inside your company. However, it may well be that you don't have and/or cannot afford the necessary hardware and admins. At some point on the spectrum, hosting your documents elsewhere becomes the better choice.
Remember, you never get absolute security. Your documents are at risk when you host them inside your company, and they are at risk when you host them outside your company. Like with all other risks, you have to account for this risk. Eventually, it becomes part of the cost-benefit analysis. And the cost-benefit analysis could swing either way: hosting internally or hosting externally.
Of course it's a bug. log10(1000) is 3, so truncating it should yield 3. Unless, of course, the specification very clearly states that operations are implemented using some kind of arithmetic that produces a different result. But, in that case, I don't want to use the software.
``We don't need another language run on what compiler people call a "naive interpreter".''
I agree. Languages like Ruby and Python are hard to beat on easy of use and programmer productivity. However, current implementations don't offer stellar performance. I think there is room for a language that allows both great programmer productivity and great performance, and the work I have been doing is all on languages that compile to efficient machine code. Besides that, I seek to integrate a number of other features, such as a syntax fit for interactive use (think Unix shell), strong checks (up to the point where you can statically prove that the program will not crash (barring failures in the underlying system)), and automatic concurrency.
While on the topic, I would like to ask a similar question. What places can people recommend for doing programming language research? I have a MSc in computer science, and I am thinking about getting back into academics after a few years of working. I have been studying and inventing programming languages as a hobby for a number of years now, and I am thinking that, perhaps, I could combine the two and do a PhD project related to programming languages. However, next time I go to university, I want the environment to be a bit more intellectually stimulating than what I have experienced so far. Since I am not tied to any specific location or even country, I have a vast number of universities I could potentially turn to. But which ones would be a good choice? Can anybody recommend some? Or perhaps I should turn to specific people, instead of universities.
``You know you can write trivial java programs without using an IDE such as Eclipse.''
Of course you can. But Java is one of those languages that really benefit from an IDE. The reason is that Java programs invariable contain a lot of boilerplate code. Since this code is repetitive and doesn't require a lot of thinking to write, writing it can easily be automated, which is what IDEs do. Other languages don't require as much boilerplate to begin with, and thus benefit less from an IDE.
``The time it takes to compile is meaningless. You only need to do it once.''
I disagree. You need to compile only once only if you get the program right the first time. This means it has to be bug free, feature complete, and never receive any updates. This may indeed work for trivial programs, but, in practical software development, it doesn't happen. You write your programs in a number of iterations, each adding some features or fixing some bugs, and then you test to see if it works as you intended. Compile time can be a significant part of this process.
``You don't have to recompile every time you run the application.''
Funny you should say that, because Java runtimes typically do exactly that. That is to say, compiling Java bytecode to native machine code. All in all, Java programs typically take quite some time to start, and take a couple of minutes to really get up to speed. This causes small, short, and linear (not a lot of loops or repetition) to underperform (e.g. you wouldn't want this behavior for Unix commands).
It's sad that it's so easy to come up with ways to save power, but so few places and people actually implement them. I even have a colleague who refuses to turn off his computer, because "a 100 W more or less doesn't matter in the grand scheme of things". He's right about that, of course, but what he and many others don't realize is that doing the little things can actually affect the grand scheme of things. I, for example, use less than half as much electricity as the average household around me, simply because I use energy-efficient products and turn off most things when I'm not using them. It's not a lot of trouble, but if everybody did it, we could easily halve the power consumed by households!
``Note: I'm not defending the Phoronix guys. As a previous poster pointed out, they are inherently bad at explaining the why things are slower and sometimes they are flat out wrong''
In that case, the best they can do is to stop talking about it and just stick to what they know. Knowing just what is faster and what is slower is useful by itself. It can be used as a starting point for investigating what exactly caused the speed-ups and slowdowns. If the Phoronix folks can't or don't want to do this investigation themselves, it's perfectly fine to leave it up to other people.
I don't understand. The attackers gained access to the database...through the backup servers? That leaves me with two questions:
1. Why were the backup servers accessible to the attacker?
2. Why was the database accessible from the backup servers?
It seems to me that the only way you need to access the backup servers is through some mechanism that allows you to transfer data to and from them. A single open port, which you need a password (or key) to use seems all that should be exposed. That shouldn't be too hard to secure.
It also seems to me that the backup server has no business accessing the database, and therefore shouldn't be able to access the database.
Unless, of course, the way the system works is that the backup server accesses the production server to retrieve the data from it. That doesn't seem the most obvious design to me, but it would at least explain why the backup server could access the database. Maybe that is a good reason not to design the system that way (on the other hand, it saves complexity on the production server, which is good). At any rate, it doesn't answer the first question, which is why the attackers were able to access the backup server.
My sympathy goes out to the WHT administrators. Good luck on recovering from this and figuring out what went wrong. I hope you will keep us posted, so that we can all learn from this incident.
``Or is it that none of the users here have any idea of physics!?''
I wouldn't go as far as to say "none of us", but I wouldn't be surprised if most people on Slashdot didn't know the ins and outs of cutting-edge particle physics. After all, Slashdot is mostly about computers, not particle physics. Given this, I find it commendable that people mostly seem to refrain from making claims about things they know nothing about. The Real World could use more of that.
``the standard sucks, big time''
Yes, I agree. I know it isn't a popular point of view, but filesystems are really databases. All the issues that apply to databases also apply to filesystems. And, as with databases, you can go a long way pretending the issues don't exist. And then get everything messed up when one of the issues does hit you.
The major difference between filesystems and databases is that, for databases, a lot of research has been done about making them efficent _and_ correct. For filesystems, a lot of work has been done on making them efficient. But, as this drama shows, not a lot of work has gone into making them efficent and _correct_. And I don't mean ext4 specifically, I mean the filesystem API itself.
What we are seeing here is basically a transaction. A file is truncated and some data are written to it. We want either both of these things to happen (commit), or neither (roll back). Now, we have two options. We can do this asynchronously, which gives good performance but no guarantee the result will be a desireable one. Or we can do it synchronously, giving good results but bad performance. And this is a simple case. Try to come up with transactions involving multiple files and you will see why the filesystem makes a very _poor_ database.
``For EXT4, if it crashes, you can get a zero-length file, with both the old and new data lost.''
Since you seem to know what you are talking about, I'm asking you. What is it that causes this data loss? Why does it happen with ext4, but not with other filesystems?
``3) The issue is not about saving data, but the atomicity of updates so that either the new data or the old data would be saved at all times.''
This is, indeed, the central issue. And it's an issue not just with filesystems, but with anything that involves concurrency or transactions (multiple things that belong together). And it's an issue that few programmers get right.
The problem is that things often appear to work if you've not done them right. As long as there is only one thread and everything that thread does is performed successfully, there isn't a problem. So the program works, let's ship it. But then, in some Real World situation, there are suddenly multiple threads and/or failing operations. This can lead to spectacular failures.
The question is, of course, who gets to bear the burden for fixing the problems. Personally, I think there is an opportunity here for programming language and library designers to create APIs that make it easier to do the right thing, and harder to do the wrong thing. But given a specific API, it's up to the programmer to use it correctly. That doesn't mean you can't complain about the API and demand better APIs, but it does mean you can't complain when something that implements the API (correctly) does not magically make your broken code do the right thing. (Not that I am claiming that is what happened in this case - I don't know enough about it to be able to judge that.)
``So, while I'm all for applications using fsync when it's really needed, the last thing I'd like to see every application on the planet sprinkling their code with fsync "just to be sure".''
In other words, there is no substitute for doing it right.
``Q: Is the certificate mismatch a security hazard?''
A: Common sense would suggest it wouldn't be in a big popup dialog labeled "WARNING" if it wasn't.
''
However, experience shows that many programs show you big scary warnings for things that aren't actually big and scary. And often for things that you actually want to do.
For an on-topic example: invalid SSL certificates. SSL provides encryption. Depending on how you use it, it also provides authentication. For authentication, you need a valid SSL certificate. Such a certificate basically states "Trusted party X says that this certificate was issued for yourbank.example.com". For this to work, you need two things: you need to trust the third party, and the party it was issued to needs to be the party you want to do business with. If any of these isn't the case, you are back to where you were without a certificate - except for one thing, you still have encryption.
Now, the funny thing is that when you use plain HTTP, you get no SSL at all, meaning no encryption and no authentication. When you use SSL with an invalid certificate, you get encryption, but no authentication. This is more secure. Yet, it will give you a big, scary warning, whereas using plain HTTP will not.
So, yes, the big scary warning is there for a reason. It means the party you are communicating with may not be who they claim to be. On the other hand, you don't usually get that assurance anyway. And, really, you don't get that assurance when using a valid SSL certificate, either. That only says the trusted party says so...but the trusted party could be wrong.
Personally, I believe they are all doing it wrong, and all in the same way. They all assume things about the programming languages that will target the VM, and build the VM to support the constructs they've assumed the language will use.
I am much more in favor of a language-agostic approach. In my own TurboVM, I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to implement languages on TurboVM. No need to work around the fact that you get objects and methods, garbage collection, dynamic typing, etc. when you don't want them - TurboVM gives what a real machine would give you, without any bias towards specific programming languages.