Yes. A very bad thing in my book, so it stings me that I would have committed that, even if unintentionally (those statements were based on my recollections from the time - which AC clearly thinks are wrong).
``Linux was never very early with desktop eye candy, sound and that sort of thing. It was a good UNIX clone but the big iron multi-user servers were hardly the greatest example in that respect. It took a long time before there was a simple way to create "normal" desktop users and not just a shell account, I remember having to manually put users in the "audio" group to get sound.''
Well, see, the thing about Linux being early is that it really depends on what you are looking at. There was a Linux distribution (Softlanding Linux System) featuring a 32-bit pre-emptive multitasking OS with a GUI and a degree of compatibility with applications written for *nix, DOS, and 16-bit Windows before there was Windows 95. That's quite an impressive feature set before the family of operating systems that Linux would be seen as a competitor to (namely the consumer versions of the Windows operating system) even existed!
Of course, virtually nobody actually knew about Linux at the time, and when Windows 95 was released, it had a lot of software and drivers written for it, a lot of new hardware was released specifically for Windows 95 (and the newly introduced Plug-n-Play), and I am sure all that completely blew contemporary Linux distros out of the water in terms of the experience one would get when installing the OS and trying to use it with ones existing or off-the-shelf hardware and software. There are a lot of similar stories, where Linux had something early on, but was later completely overtaken by Windows. For example, I remember seeing WLAN support in Linux long before most people had even heard of it, but after that we got into the situation where having your WLAN card work in Windows was a given, whereas in Linux it was hit and miss, missing more often than hitting. I can see where the impression that Linux is always playing catch-up is coming from, but it got a lot of things a lot earlier than many people know.
I am all for you correcting me when I get my facts wrong. In fact, I encourage everyone to do so! However, it hurts me that you had to do it in such strong terms. For the record, my intent was not to make Windows look bad, but rather to correct the (in my eyes, errorneous) view that sound on Linux has always been a "cluster fornication". Regardless of what Windows did or didn't do at the time, I was impressed by ESD at the time.
Now, with regard to the claim that Windows 95 and Windows 98 did not play multiple sounds at the same time, I may be wrong about that. I am sure they would have been able to, given the right software. I am also sure that when my Linux box played sounds from multiple applications simultaneously, I was as surprised as I was because I had never experienced that before. My recollection is that this certainly wasn't common practice on Windows at the time. If you can make a convincing argument that multiple applications simultaneously playing sound was common on Windows at the time, I stand corrected.
``Funny how the Linux crowd here decries FUD and shouts loudly about marketing based on facts, until it's their turn to make up some random piece of absolute horseshit to make Windows look bad, and then suddenly it's +4 interesting.''
That would be a very bad thing. There is already enough ignorance, misconception, stereotyping, and aggression in the world without anyone actively adding more. I am trying to do my part to correct that, so if you find factual errors in my statements, please do point them out!
``But lets be honest. Sound in Linux has always been a cluster fornication.''
I don't know, man. OSS always worked for me. Then came ESD, which worked on top of OSS but allowed multiple applications to play sounds at the same time. I actually fell from my chair the first time that happened. I had never heard that before. It didn't happen on Windows at the time, despite Windows being king then. Clusterfornication? I wouldn't say so.
Then we got ALSA. I never really understood the point of that. Eventually, free OSS drivers stopped being available for my hardware, but ALSA drivers were available, so I switched. It worked, although a few applications I used needed configuration changes, because they tried to use OSS and failed, ALSA's OSS emulation notwithstanding. I understand other people's experience with ALSA hasn't been as good, but I suspect that has something to do with them switching years before I did.
There have been several other audio systems that I never understood the point of and never used. And then came PulseAudio. What on Earth happened there? Seriously. One day, I was sitting happily thinking how Linux distros had matured so much over the years, and then suddenly, millions of computers went silent, and a million voices cried out in pain and frustration. I don't know what benefits PulseAudio has, but it's clear that somebody screwed up by mass-deploying it when it clearly didn't work reliably yet. I actually think that this debacle has single-handedly reduced the reputation of sound on Linux from "it works, as long as your hardware is supported, which it generally is" to "you are lucky if it works at all, and even luckier if it still works tomorrow". Congratulations, that was quite an accomplishment.
``Honestly, if you're buying closed hardware, you might as well take the dive and download (for free) the closed software to support it.''
I would be hesitant to paint hardware and software with the same brush. For one thing, software has practically zero marginal cost, whereas there is a real cost to producing another unit of hardware. For another, hardware is largely an isolated piece of the system, which only interacts with the rest of the system through well-defined interfaces (at the hardware level, that is).
``Drivers are just software glue to connect hardware to your OS.''
If only that were the case. Drivers, at least on Linux, basically have kernel-level access to the system, which makes them part of the trusted base. That does not combine well with not being able to inspect, much less modify the working of the driver. It could be full of (intentional or unintentional) security holes and other bugs you might never know. And even if you knew, you wouldn't be allowed to fix them. I am sure there are known cases of such security holes. And haven't Windows users been saying for a number of years now that the major cause of crashes on their OS is faulty drivers?
Even if a driver is just software glue to connect hardware to your OS, and it does not compromise the security and stability of your system, it would still be software glue between the hardware and _that_ OS. Experience shows that there are generally only a very limited number of operating systems that are supported by vendor-supplied drivers. Good luck if you ever want to use the hardware with another OS, or develop a new OS. Even a different version of the same OS can be, and often has been, problematic.
Finally, I think even having the debate about open vs. closed drivers is the wrong discussion. By the time you are dependent on there being a driver, you have already lost the greater battle. There _should_ be a well-defined programming interface to the hardware, at least in so far as the hardware exposes functionality that is commonly provided by such hardware. I am thinking about things like ATAPI, VGA, USB device classes, serial port controllers, etc. When devices conform to these standards or de-facto standards, you can buy a device from any vendor and have it work by programming it the same way you would any other such device. For graphics cards, we have OpenGL. That means we know what the graphics card is expected to be able to do. Why isn't there a standard way to make it do that?
Even failing a vendor-neutral way of programming the hardware, there should at least be a specification of the interface to the hardware. It used to be the case that you got these: the printer communicates over the parallel port and here is a description of the command language it supports. For CPUs, as far as I know, this information is also generally available. It seems to me that AMD is now doing the same thing for their graphics cards, as well. They don't all work the same way, but at least you can get a document that explains how they do work. Without that, it's either there's a good driver, or you're simply out of luck. My experience is that this alone means, in practice, that the hardware vendors dictate what operating systems you can use and when you can or must upgrade - and I say "no, thanks" to that.
``Perhaps there would be better reception for all of these new OGL iterations if they saved up some worthwhile features before putting them into the spec, and just leave the new stuff as extensions until they have a nice upgrade to show.''
My understanding is that they used to do that, but got overtaken by Direct3D because people thought OpenGL was stagnant.
I agree with you, though. As long as it can be put in extensions, that is a nice way of advancing the capabilities of your system without polluting the core standard with things that, perhaps, nobody will be using anymore 10 years from now. On the other hand, if a bump in version number makes the world happy, then why not? You can always cook up a new standard to get rid of the bloat (as exemplified by OpenGL ES).
That's close to what my school did. Nominally a catholic school, they had a compulsory subject where they taught the basics of the major religions of the world. I'm happy I had that course, because people like it when you understand a bit of their religion. Oh, they taught evolution, too, in biology class. Somehow, this wasn't a big deal, though. I don't recall anybody demanding only their views be taught.
``Except in Europe WWI and WWII happened and we kinda grew up.''
I don't know, man. WWI started after Gavrilo Princip killed archduke Franz Ferdinand of Austria, as part of a struggle for independence for yugoslavs. This was in 1914. Through the 1990s, there have been wars for independence inside and between the former constituent republics of Yugoslavia, including a very bloody one in Bosnia. Troops from European states as well as the USA have been involved. There is talk that the serbs in Bosnia and Herzegovina want to split of from the rest. I'd say that the conflict isn't over yet.
Also, let's not forget that a lot of former colonies of European states only gained their independence _after_ WWII, often after bloody attempts by the colonialists to squash the independence movement.
Nowadays, troops from European states go on "peace missions", which encompasses anything from protecting an area against invasion from outside that area to actually seeking out and "engaging" enemy "fighters" to secure the position of a government more friendly towards the West in place of the government that used to rule the area.
I'm from Europe, and I'm really not so sure we have grown up over here.
I wonder if Linux can work reliably off an USB stick, though. A couple of years ago I decided to start using only flash memory for storage and got a couple of CompactFlash cards and USB card readers. Contrary to what I expected, system boot time actually increased a lot, and after a while, the system would just freeze while performing I/O. I gave up and went back to using harddisks.
``The atom has a TDP of 8-14 W while the Athlon II is between 25-65 W. If you let both machines run for two years, then the combined purchasing price + the running cost put the Athlon in a very unfavorable spot, especially if you don't need the processing power on a regular basis.''
On the other hand, the TDP is (as far as understand it) an upper bound on what the CPU could draw. If you do need the processing power on a regular basis, then you may get close to the power figures stated - but then the Athlon II allegedly (I didn't verify the claims) also gets you a lot more processing power. If you don't need the full processing power (the more likely scenario), then you will also not use as much power. The Athlon II CPUs in this chart use about 7 W when idle. I don't know what an Intel Atom uses when idle, but I wonder if it leaves a very large difference. At some point, when you want to save power, the best thing to do is to simply turn off the computer.
Correct. I have actually worked at organizations where they used a certificate signed by their own certificate whenever you accessed something over HTTPS. And since they had added their certificate to the trusted list in Internet Explorer, very few people actually noticed. I did not access my e-mail or enter any passwords not already known to those organizations over those links.
``Unless the wifi network is at a Starbucks, a university or a corporation.
That creepy guy sitting two tables from you at the coffee shop? He can now read your e-mail.''
Not unless he also knows how to break SSL. I've never assumed that any path between me and my mail server was secure, whether wired or wireless, WEP or WPA. So I only read mail over end-to-end encrypted protocols. Of course, most people still send e-mail through unencrypted SMTP, and without very reliable authentication, so I assume neither that e-mail is private, nor that it comes from whom it purports to come from. The protocols just don't work that way.
While I find Wine really impressive and congratulate all the contributors on what has been achieved, one of the persistent problems with Wine is how unpredictable it is. An applications might work flawlessly on one system and be unusable on another. My impression is that this has improved a lot since Wine 1.0 and the policy that newer Wine releases shall not break applications that were working before, and I count that as one of the most significant improvements ever to have been made. Still, if you take a look at pretty much any given application in AppDb, you will find wildly differing degrees of success and contradictory advice about whether patches or winetricks should or should not be applied for best results. There is still room for improvement there.
While I agree with you that we shouldn't be too quick to conclude that we need nuclear power, I would like to add a couple of points to the discussion:
1. When you say "I think its best not to buy into the pipe dream of Nuclear Fusion until its actually practical", you are correct in that it probably wouldn't be a good idea to buy into a pipe dream, but the question is if nuclear fusion is one. As far as I know, nuclear fusion does produce energy, and we have working reactors - we just don't have reactors that produce more power than they consume yet. If we don't do further research, we will surely never get them, either. I personally feel that electricity from fusion is quite a bit more realistic than your average pipe dream, so using the pipe dream argument to halt development in its tracks feels wrong to me.
2. While I agree with you that "scaremongering is hard to avoid", I don't see that as much of an argument against nuclear power. Sure, it will drive up the cost. But that doesn't mean nuclear power is actually a bad idea. It just means that the scaremongering makes it more expensive than it would otherwise have been.
3. When you say: "PRACTISE is very different...and very dangerous... just think of all the past nuclear leaks, radiation, the pollution, the stockpiling of waste...", I agree with your point about the stockpiling of nuclear waste. However, I don't think nuclear fission is quite as dangerous as you make it out to be. There are lots of fission plants being operated all over the Earth, some small research plants, some large power plants, and some aboard submarines. How much of an impact is this having on your safety? My guess is "not really all that much".
4. With respect to storage of nuclear waste, I think this is a big problem, and one that is often too easily dismissed by proponents of nuclear energy. Especially proponents of fusion; they like to pretend it will be completely clean, but I am not convinced. It is worth noting, however, that other energy sources have problems, too. Greenhouse gasses from the burning of fossil fuels are well known but, in my opinion, often too easily dismissed. What is less widely known is that plants operating on fossil fuels also emit radioactive waste - but unlike the waste from nuclear plants, the waste from plants that burn fuel is usually emitted in the air, where it can spread, be breathed, etc. What I am trying to say here is that, although the debate is largely focused on a few issues that are hotly debated, we really need to take a careful look at all the factors, and go with the energy source that is best, overall. I don't have a problem with radioactive waste if it is collected, stored, and reduced to background-level radioactivity in a matter of decades. I've seen some research that promises to give us that, though I can't find the link right now.
As a closing remark, let me add that I wholeheartedly agree with your statement that we shouldn't be polluting this or any other planet if we have a choice. Ideally, everything we do should be sustainable, and I welcome any research that gives us more ways to live sustainably.
Video calling has been around for a long time, at least 10 years or so. It has never taken off before. Perhaps that will change now that the iPhone has it.
Thanks for your answer! I forgot to mention this in my earlier message, but I'm actually using InnoDB tables (I need ACID to be able to sleep at night). As far as I understand, the problem has something to do with locking, indices, and auto_increment. How that causes a deadlock isn't clear to me; I would expect both transactions to acquire the locks pertaining to the same table in the same order, which would avoid the problem. Apparently, that isn't the way it works, at least in that version of MySQL.
I am aware of PostgreSQL's MVCC, which is why I was wondering if PostgreSQL may perhaps avoid the problem that MySQL runs into. The reason that I can't answer that question for myself is that I don't know exactly how or why MySQL ties itself into a knot.
Perhaps slightly off-topic, but I would like to throw this question out here in case someone has an answer:
The other day I was working on an application that uses a MySQL database. I found that when hammering the application with hundreds of actions that caused data to be inserted in the database, I would often get a message to the effect that a deadlock had been detected, with the advice to "try restarting the transaction". In the cases I investigated, the deadlocks were caused by two transactions trying to insert into the same table. I don't really understand why this causes a deadlock. Is this something I could expect to happen with any RDBMS (e.g. because I'm doing something wrong or because this is simply unavoidable), or is it related to implementation choices? Under what circumstances does and doesn't PostgreSQL deadlock?
``PostgreSQL has been a better database for a long time now. The pull of MySQL isn't its technical prowess but its "dumbness." Simply put, MySQL provides a lot in exchange for very little.''
At least, it used to be that way before MySQL grew a more complete set of features while at the same time growing some annoying bugs. Now it _looks_ like MySQL is a proper RDBMS, and people still think it's easy to use like in the 3.x days. In so far as that is true, it's great - but my experience is that, sooner or later, you are going to get bitten by one of the bugs. I haven't yet into one that I couldn't figure out a workaround for, but it does destroy the ease of use - and I doubt MySQL has much of an edge over PostgreSQL there to begin with. Don't get me wrong, MySQL is useful and it has certainly grown a lot since I took my first steps with it, but if I had known then what I know now, I would have gone with PostgreSQL to begin with.
Having said that, I wish both projects best of luck. They're doing a good job and making the world a better place, as do the various other useful open-source database systems.
I wouldn't. Both Google and German government are made up of people. There will be good people and bad people in both organizations.
The major differences are that the the German government has a rather limited sphere of influence and you have some control over it through elections and other measures, like demonstrations, campaigns, founding your own party, etc. You vote along with a lot of citizens who are in the same boat as you are.
On the other hand, Google operates world-wide, and I doubt that you have a lot of control over their actions unless you work for them. Sure, you can buy shares and have a vote, but it will be your vote among that of a lot of people who don't know and/or don't care what happens in Germany.
Speaking for myself, I would rather keep my data away from both the government and large multinational companies. I am certainly no more comfortable with Google having it than with my (Dutch) government having it. And, as this case demonstrates, it doesn't necessarily matter who collects the data - you may be more comfortable with Google collecting it than with your government collecting it, but it looks like now both Google and the government are going to have it.
``Chrome is an immature browser based on one of the newer rendering engines, so we expect it to mature rapidly, but hardly can expect it to match it's cousin Safari in most areas, thous we expect it would in a short time.''
I think that depends on how you look at it. Chrome's rendering engine is based on an older version of the rendering engine from Safari, which is in turn based on KHTML from Konqueror, which was forked from khtmlw in 1998, making it about as old as the Gecko engine used by Mozilla. While Chrome's engine has supported the multi-process model for some time, Safari's only started on that in April 2010, I think. So if you are looking for maturity, I am not so sure Safari is a better bet than Chrome.
``Why should we let Apple (or any other company) abdicate responsibility for their supply chain?''
Well, I see it like this: Apple (or any other company) wants something manufactured. So they approach some manufacturers to make them an offer. Foxconn (or any other bidder) says "We can do it for so and so much." Among all the bidders, Foxconn has the most attractive offer, and Apple believes they will be able to make good on it, so they sign the deal.
Is that all there is to it? Well, pretty much yes. If Apple didn't trust Foxconn enough, they probably wouldn't sign the deal. This trust can cover anything from fear that Foxconn might go belly up before having delivered, to causing negative press for Apple. In the end, there is no real way for Apple to be certain that such events will happen, or will not happen, if they sign the deal with any of the bidders. The best they can do is make a risk assessment, pick the winner of the bid, encourage them to do the right thing, work with them to help them do the right thing, and help fix things if things still go wrong. And it seems to me that this is exactly what they are doing.
``If Apple chooses to work with Foxconn, then Apple is on the hook for ensuring Foxconn is a reputable and humane supplier.''
I think that's debatable. Certainly, you may _like_ Apple to try its best to ensure that every supplier they work with is reputable and humane. And maybe they are doing that. They are, after all, paying extra to support the plan to curb the suicides. But even if Apple do their best, there is only so much they can do. They don't control Foxconn, and, last I checked, Apple didn't have a standing army or a special ops unit that could force Foxconn to do what Apple would like them to do. So it's really Foxconn that has to fix things - Apple can only encourage them, help them, and, if that fails, walk away from Foxconn and distance themselves from Foxconn's practices should Foxconn not clean up its act. So I really thing "ensuring" is too strong. Apple can't do that, so it's unreasonable to expect that of them.
``How can you compare workers with the general population?''
Well, why wouldn't you? And if conditions at Foxconn are indeed supposed to increase suicide rate, wouldn't you expect the suicide rate at Foxconn to be _higher_ than in the general population? I reckon that it would be more meaningful to compare the suicide rate of Chinese Foxconn employees to the Chinese general population than to the US general population, but still - wouldn't the numbers cited by the grandparent indicate that your risk of committing suicide would be higher if you lived in the USA than if you lived in China and worked for Foxconn?
Personally, I am not so sure giving the workers a raise is the most efficient way for the company to prevent the suicides. I have never known anyone to commit suicide simply because they felt they weren't making enough money. The more likely culprit, I think, is high stress levels - which may be caused by having trouble making ends meet due to inadequate wages, but would surely also be related to the working environment and the workload. Rather than raising wages by 20%, I would think that, say, hiring 20% more people to lighten the load would be more effective. Probably, the suicides are caused by a combination of factors, which suggests that they are also best combated by a combination of improvements.
Slashdot Mirror
``I'll add historical revisionism to that list.''
Yes. A very bad thing in my book, so it stings me that I would have committed that, even if unintentionally (those statements were based on my recollections from the time - which AC clearly thinks are wrong).
``Linux was never very early with desktop eye candy, sound and that sort of thing. It was a good UNIX clone but the big iron multi-user servers were hardly the greatest example in that respect. It took a long time before there was a simple way to create "normal" desktop users and not just a shell account, I remember having to manually put users in the "audio" group to get sound.''
Well, see, the thing about Linux being early is that it really depends on what you are looking at. There was a Linux distribution (Softlanding Linux System) featuring a 32-bit pre-emptive multitasking OS with a GUI and a degree of compatibility with applications written for *nix, DOS, and 16-bit Windows before there was Windows 95. That's quite an impressive feature set before the family of operating systems that Linux would be seen as a competitor to (namely the consumer versions of the Windows operating system) even existed!
Of course, virtually nobody actually knew about Linux at the time, and when Windows 95 was released, it had a lot of software and drivers written for it, a lot of new hardware was released specifically for Windows 95 (and the newly introduced Plug-n-Play), and I am sure all that completely blew contemporary Linux distros out of the water in terms of the experience one would get when installing the OS and trying to use it with ones existing or off-the-shelf hardware and software. There are a lot of similar stories, where Linux had something early on, but was later completely overtaken by Windows. For example, I remember seeing WLAN support in Linux long before most people had even heard of it, but after that we got into the situation where having your WLAN card work in Windows was a given, whereas in Linux it was hit and miss, missing more often than hitting. I can see where the impression that Linux is always playing catch-up is coming from, but it got a lot of things a lot earlier than many people know.
Dear AC,
I am all for you correcting me when I get my facts wrong. In fact, I encourage everyone to do so! However, it hurts me that you had to do it in such strong terms. For the record, my intent was not to make Windows look bad, but rather to correct the (in my eyes, errorneous) view that sound on Linux has always been a "cluster fornication". Regardless of what Windows did or didn't do at the time, I was impressed by ESD at the time.
Now, with regard to the claim that Windows 95 and Windows 98 did not play multiple sounds at the same time, I may be wrong about that. I am sure they would have been able to, given the right software. I am also sure that when my Linux box played sounds from multiple applications simultaneously, I was as surprised as I was because I had never experienced that before. My recollection is that this certainly wasn't common practice on Windows at the time. If you can make a convincing argument that multiple applications simultaneously playing sound was common on Windows at the time, I stand corrected.
``Funny how the Linux crowd here decries FUD and shouts loudly about marketing based on facts, until it's their turn to make up some random piece of absolute horseshit to make Windows look bad, and then suddenly it's +4 interesting.''
That would be a very bad thing. There is already enough ignorance, misconception, stereotyping, and aggression in the world without anyone actively adding more. I am trying to do my part to correct that, so if you find factual errors in my statements, please do point them out!
``But lets be honest. Sound in Linux has always been a cluster fornication.''
I don't know, man. OSS always worked for me. Then came ESD, which worked on top of OSS but allowed multiple applications to play sounds at the same time. I actually fell from my chair the first time that happened. I had never heard that before. It didn't happen on Windows at the time, despite Windows being king then. Clusterfornication? I wouldn't say so.
Then we got ALSA. I never really understood the point of that. Eventually, free OSS drivers stopped being available for my hardware, but ALSA drivers were available, so I switched. It worked, although a few applications I used needed configuration changes, because they tried to use OSS and failed, ALSA's OSS emulation notwithstanding. I understand other people's experience with ALSA hasn't been as good, but I suspect that has something to do with them switching years before I did.
There have been several other audio systems that I never understood the point of and never used. And then came PulseAudio. What on Earth happened there? Seriously. One day, I was sitting happily thinking how Linux distros had matured so much over the years, and then suddenly, millions of computers went silent, and a million voices cried out in pain and frustration. I don't know what benefits PulseAudio has, but it's clear that somebody screwed up by mass-deploying it when it clearly didn't work reliably yet. I actually think that this debacle has single-handedly reduced the reputation of sound on Linux from "it works, as long as your hardware is supported, which it generally is" to "you are lucky if it works at all, and even luckier if it still works tomorrow". Congratulations, that was quite an accomplishment.
``Honestly, if you're buying closed hardware, you might as well take the dive and download (for free) the closed software to support it.''
I would be hesitant to paint hardware and software with the same brush. For one thing, software has practically zero marginal cost, whereas there is a real cost to producing another unit of hardware. For another, hardware is largely an isolated piece of the system, which only interacts with the rest of the system through well-defined interfaces (at the hardware level, that is).
``Drivers are just software glue to connect hardware to your OS.''
If only that were the case. Drivers, at least on Linux, basically have kernel-level access to the system, which makes them part of the trusted base. That does not combine well with not being able to inspect, much less modify the working of the driver. It could be full of (intentional or unintentional) security holes and other bugs you might never know. And even if you knew, you wouldn't be allowed to fix them. I am sure there are known cases of such security holes. And haven't Windows users been saying for a number of years now that the major cause of crashes on their OS is faulty drivers?
Even if a driver is just software glue to connect hardware to your OS, and it does not compromise the security and stability of your system, it would still be software glue between the hardware and _that_ OS. Experience shows that there are generally only a very limited number of operating systems that are supported by vendor-supplied drivers. Good luck if you ever want to use the hardware with another OS, or develop a new OS. Even a different version of the same OS can be, and often has been, problematic.
Finally, I think even having the debate about open vs. closed drivers is the wrong discussion. By the time you are dependent on there being a driver, you have already lost the greater battle. There _should_ be a well-defined programming interface to the hardware, at least in so far as the hardware exposes functionality that is commonly provided by such hardware. I am thinking about things like ATAPI, VGA, USB device classes, serial port controllers, etc. When devices conform to these standards or de-facto standards, you can buy a device from any vendor and have it work by programming it the same way you would any other such device. For graphics cards, we have OpenGL. That means we know what the graphics card is expected to be able to do. Why isn't there a standard way to make it do that?
Even failing a vendor-neutral way of programming the hardware, there should at least be a specification of the interface to the hardware. It used to be the case that you got these: the printer communicates over the parallel port and here is a description of the command language it supports. For CPUs, as far as I know, this information is also generally available. It seems to me that AMD is now doing the same thing for their graphics cards, as well. They don't all work the same way, but at least you can get a document that explains how they do work. Without that, it's either there's a good driver, or you're simply out of luck. My experience is that this alone means, in practice, that the hardware vendors dictate what operating systems you can use and when you can or must upgrade - and I say "no, thanks" to that.
``Perhaps there would be better reception for all of these new OGL iterations if they saved up some worthwhile features before putting them into the spec, and just leave the new stuff as extensions until they have a nice upgrade to show.''
My understanding is that they used to do that, but got overtaken by Direct3D because people thought OpenGL was stagnant.
I agree with you, though. As long as it can be put in extensions, that is a nice way of advancing the capabilities of your system without polluting the core standard with things that, perhaps, nobody will be using anymore 10 years from now. On the other hand, if a bump in version number makes the world happy, then why not? You can always cook up a new standard to get rid of the bloat (as exemplified by OpenGL ES).
That's close to what my school did. Nominally a catholic school, they had a compulsory subject where they taught the basics of the major religions of the world. I'm happy I had that course, because people like it when you understand a bit of their religion. Oh, they taught evolution, too, in biology class. Somehow, this wasn't a big deal, though. I don't recall anybody demanding only their views be taught.
``Except in Europe WWI and WWII happened and we kinda grew up.''
I don't know, man. WWI started after Gavrilo Princip killed archduke Franz Ferdinand of Austria, as part of a struggle for independence for yugoslavs. This was in 1914. Through the 1990s, there have been wars for independence inside and between the former constituent republics of Yugoslavia, including a very bloody one in Bosnia. Troops from European states as well as the USA have been involved. There is talk that the serbs in Bosnia and Herzegovina want to split of from the rest. I'd say that the conflict isn't over yet.
Also, let's not forget that a lot of former colonies of European states only gained their independence _after_ WWII, often after bloody attempts by the colonialists to squash the independence movement.
Nowadays, troops from European states go on "peace missions", which encompasses anything from protecting an area against invasion from outside that area to actually seeking out and "engaging" enemy "fighters" to secure the position of a government more friendly towards the West in place of the government that used to rule the area.
I'm from Europe, and I'm really not so sure we have grown up over here.
I wonder if Linux can work reliably off an USB stick, though. A couple of years ago I decided to start using only flash memory for storage and got a couple of CompactFlash cards and USB card readers. Contrary to what I expected, system boot time actually increased a lot, and after a while, the system would just freeze while performing I/O. I gave up and went back to using harddisks.
``The atom has a TDP of 8-14 W while the Athlon II is between 25-65 W. If you let both machines run for two years, then the combined purchasing price + the running cost put the Athlon in a very unfavorable spot, especially if you don't need the processing power on a regular basis.''
On the other hand, the TDP is (as far as understand it) an upper bound on what the CPU could draw. If you do need the processing power on a regular basis, then you may get close to the power figures stated - but then the Athlon II allegedly (I didn't verify the claims) also gets you a lot more processing power. If you don't need the full processing power (the more likely scenario), then you will also not use as much power. The Athlon II CPUs in this chart use about 7 W when idle. I don't know what an Intel Atom uses when idle, but I wonder if it leaves a very large difference. At some point, when you want to save power, the best thing to do is to simply turn off the computer.
Correct. I have actually worked at organizations where they used a certificate signed by their own certificate whenever you accessed something over HTTPS. And since they had added their certificate to the trusted list in Internet Explorer, very few people actually noticed. I did not access my e-mail or enter any passwords not already known to those organizations over those links.
``Unless the wifi network is at a Starbucks, a university or a corporation.
That creepy guy sitting two tables from you at the coffee shop? He can now read your e-mail.''
Not unless he also knows how to break SSL. I've never assumed that any path between me and my mail server was secure, whether wired or wireless, WEP or WPA. So I only read mail over end-to-end encrypted protocols. Of course, most people still send e-mail through unencrypted SMTP, and without very reliable authentication, so I assume neither that e-mail is private, nor that it comes from whom it purports to come from. The protocols just don't work that way.
While I find Wine really impressive and congratulate all the contributors on what has been achieved, one of the persistent problems with Wine is how unpredictable it is. An applications might work flawlessly on one system and be unusable on another. My impression is that this has improved a lot since Wine 1.0 and the policy that newer Wine releases shall not break applications that were working before, and I count that as one of the most significant improvements ever to have been made. Still, if you take a look at pretty much any given application in AppDb, you will find wildly differing degrees of success and contradictory advice about whether patches or winetricks should or should not be applied for best results. There is still room for improvement there.
While I agree with you that we shouldn't be too quick to conclude that we need nuclear power, I would like to add a couple of points to the discussion:
1. When you say "I think its best not to buy into the pipe dream of Nuclear Fusion until its actually practical", you are correct in that it probably wouldn't be a good idea to buy into a pipe dream, but the question is if nuclear fusion is one. As far as I know, nuclear fusion does produce energy, and we have working reactors - we just don't have reactors that produce more power than they consume yet. If we don't do further research, we will surely never get them, either. I personally feel that electricity from fusion is quite a bit more realistic than your average pipe dream, so using the pipe dream argument to halt development in its tracks feels wrong to me.
2. While I agree with you that "scaremongering is hard to avoid", I don't see that as much of an argument against nuclear power. Sure, it will drive up the cost. But that doesn't mean nuclear power is actually a bad idea. It just means that the scaremongering makes it more expensive than it would otherwise have been.
3. When you say: "PRACTISE is very different...and very dangerous... just think of all the past nuclear leaks, radiation, the pollution, the stockpiling of waste...", I agree with your point about the stockpiling of nuclear waste. However, I don't think nuclear fission is quite as dangerous as you make it out to be. There are lots of fission plants being operated all over the Earth, some small research plants, some large power plants, and some aboard submarines. How much of an impact is this having on your safety? My guess is "not really all that much".
4. With respect to storage of nuclear waste, I think this is a big problem, and one that is often too easily dismissed by proponents of nuclear energy. Especially proponents of fusion; they like to pretend it will be completely clean, but I am not convinced. It is worth noting, however, that other energy sources have problems, too. Greenhouse gasses from the burning of fossil fuels are well known but, in my opinion, often too easily dismissed. What is less widely known is that plants operating on fossil fuels also emit radioactive waste - but unlike the waste from nuclear plants, the waste from plants that burn fuel is usually emitted in the air, where it can spread, be breathed, etc. What I am trying to say here is that, although the debate is largely focused on a few issues that are hotly debated, we really need to take a careful look at all the factors, and go with the energy source that is best, overall. I don't have a problem with radioactive waste if it is collected, stored, and reduced to background-level radioactivity in a matter of decades. I've seen some research that promises to give us that, though I can't find the link right now.
As a closing remark, let me add that I wholeheartedly agree with your statement that we shouldn't be polluting this or any other planet if we have a choice. Ideally, everything we do should be sustainable, and I welcome any research that gives us more ways to live sustainably.
``Offtopic or not, what it the glorious melted cheese fuck is up with the new BSA advertisements on Slashdot?''
What's wrong with the BSA?
Video calling has been around for a long time, at least 10 years or so. It has never taken off before. Perhaps that will change now that the iPhone has it.
Thanks for your answer! I forgot to mention this in my earlier message, but I'm actually using InnoDB tables (I need ACID to be able to sleep at night). As far as I understand, the problem has something to do with locking, indices, and auto_increment. How that causes a deadlock isn't clear to me; I would expect both transactions to acquire the locks pertaining to the same table in the same order, which would avoid the problem. Apparently, that isn't the way it works, at least in that version of MySQL.
I am aware of PostgreSQL's MVCC, which is why I was wondering if PostgreSQL may perhaps avoid the problem that MySQL runs into. The reason that I can't answer that question for myself is that I don't know exactly how or why MySQL ties itself into a knot.
Perhaps slightly off-topic, but I would like to throw this question out here in case someone has an answer:
The other day I was working on an application that uses a MySQL database. I found that when hammering the application with hundreds of actions that caused data to be inserted in the database, I would often get a message to the effect that a deadlock had been detected, with the advice to "try restarting the transaction". In the cases I investigated, the deadlocks were caused by two transactions trying to insert into the same table. I don't really understand why this causes a deadlock. Is this something I could expect to happen with any RDBMS (e.g. because I'm doing something wrong or because this is simply unavoidable), or is it related to implementation choices? Under what circumstances does and doesn't PostgreSQL deadlock?
``PostgreSQL has been a better database for a long time now. The pull of MySQL isn't its technical prowess but its "dumbness." Simply put, MySQL provides a lot in exchange for very little.''
At least, it used to be that way before MySQL grew a more complete set of features while at the same time growing some annoying bugs. Now it _looks_ like MySQL is a proper RDBMS, and people still think it's easy to use like in the 3.x days. In so far as that is true, it's great - but my experience is that, sooner or later, you are going to get bitten by one of the bugs. I haven't yet into one that I couldn't figure out a workaround for, but it does destroy the ease of use - and I doubt MySQL has much of an edge over PostgreSQL there to begin with. Don't get me wrong, MySQL is useful and it has certainly grown a lot since I took my first steps with it, but if I had known then what I know now, I would have gone with PostgreSQL to begin with.
Having said that, I wish both projects best of luck. They're doing a good job and making the world a better place, as do the various other useful open-source database systems.
Alright, so do you have links to those cheap USB monitors you are talking about? I seem to have trouble finding them.
``I trust Google more than German officials''
I wouldn't. Both Google and German government are made up of people. There will be good people and bad people in both organizations.
The major differences are that the the German government has a rather limited sphere of influence and you have some control over it through elections and other measures, like demonstrations, campaigns, founding your own party, etc. You vote along with a lot of citizens who are in the same boat as you are.
On the other hand, Google operates world-wide, and I doubt that you have a lot of control over their actions unless you work for them. Sure, you can buy shares and have a vote, but it will be your vote among that of a lot of people who don't know and/or don't care what happens in Germany.
Speaking for myself, I would rather keep my data away from both the government and large multinational companies. I am certainly no more comfortable with Google having it than with my (Dutch) government having it. And, as this case demonstrates, it doesn't necessarily matter who collects the data - you may be more comfortable with Google collecting it than with your government collecting it, but it looks like now both Google and the government are going to have it.
``Chrome is an immature browser based on one of the newer rendering engines, so we expect it to mature rapidly, but hardly can expect it to match it's cousin Safari in most areas, thous we expect it would in a short time.''
I think that depends on how you look at it. Chrome's rendering engine is based on an older version of the rendering engine from Safari, which is in turn based on KHTML from Konqueror, which was forked from khtmlw in 1998, making it about as old as the Gecko engine used by Mozilla. While Chrome's engine has supported the multi-process model for some time, Safari's only started on that in April 2010, I think. So if you are looking for maturity, I am not so sure Safari is a better bet than Chrome.
``Why should we let Apple (or any other company) abdicate responsibility for their supply chain?''
Well, I see it like this: Apple (or any other company) wants something manufactured. So they approach some manufacturers to make them an offer. Foxconn (or any other bidder) says "We can do it for so and so much." Among all the bidders, Foxconn has the most attractive offer, and Apple believes they will be able to make good on it, so they sign the deal.
Is that all there is to it? Well, pretty much yes. If Apple didn't trust Foxconn enough, they probably wouldn't sign the deal. This trust can cover anything from fear that Foxconn might go belly up before having delivered, to causing negative press for Apple. In the end, there is no real way for Apple to be certain that such events will happen, or will not happen, if they sign the deal with any of the bidders. The best they can do is make a risk assessment, pick the winner of the bid, encourage them to do the right thing, work with them to help them do the right thing, and help fix things if things still go wrong. And it seems to me that this is exactly what they are doing.
``If Apple chooses to work with Foxconn, then Apple is on the hook for ensuring Foxconn is a reputable and humane supplier.''
I think that's debatable. Certainly, you may _like_ Apple to try its best to ensure that every supplier they work with is reputable and humane. And maybe they are doing that. They are, after all, paying extra to support the plan to curb the suicides. But even if Apple do their best, there is only so much they can do. They don't control Foxconn, and, last I checked, Apple didn't have a standing army or a special ops unit that could force Foxconn to do what Apple would like them to do. So it's really Foxconn that has to fix things - Apple can only encourage them, help them, and, if that fails, walk away from Foxconn and distance themselves from Foxconn's practices should Foxconn not clean up its act. So I really thing "ensuring" is too strong. Apple can't do that, so it's unreasonable to expect that of them.
``How can you compare workers with the general population?''
Well, why wouldn't you? And if conditions at Foxconn are indeed supposed to increase suicide rate, wouldn't you expect the suicide rate at Foxconn to be _higher_ than in the general population? I reckon that it would be more meaningful to compare the suicide rate of Chinese Foxconn employees to the Chinese general population than to the US general population, but still - wouldn't the numbers cited by the grandparent indicate that your risk of committing suicide would be higher if you lived in the USA than if you lived in China and worked for Foxconn?
Personally, I am not so sure giving the workers a raise is the most efficient way for the company to prevent the suicides. I have never known anyone to commit suicide simply because they felt they weren't making enough money. The more likely culprit, I think, is high stress levels - which may be caused by having trouble making ends meet due to inadequate wages, but would surely also be related to the working environment and the workload. Rather than raising wages by 20%, I would think that, say, hiring 20% more people to lighten the load would be more effective. Probably, the suicides are caused by a combination of factors, which suggests that they are also best combated by a combination of improvements.
``I suspect hell is much like corporate america, but with better benefits and more free time.''
That sounds a lot like western Europe. It's actually quite nice over here.