Also, there is a big push underway, with widespread support -- even from some artists groups -- to legalize file sharing in exchange for a small levy (~$1.74/month) on your broadband connection.
Fuck that. I don't infringe copyright. Don't steal my money.''
While I agree that it isn't fair to make you pay for something you don't use, I still think there is something to this proposal. Consider the alternatives. One alternative I am aware of is the system as implemented in the USA: distributing copyrighted works without permission is illegal, but still widespread. In response, increasingly draconian measures are being instated by the government, and being accused of distributing or obtaining copyrighted works without permission leads to either high court fees, or high settlement payments. Moreover, government resources are used in at least some copyright cases. Is that the society you want to live in? Remember, all those things affect you, too, even if you (like me) don't participate in unauthorized copying of copyrighted works.
I realize that proposed-brazillian-system vs. actual-US-system is a false dichotomy, so if you can find an alternative that is better than either, especially if there is a chance that it will actually be implemented, I would like to hear about that, too.
Some European Union member states (at least the Netherlands) have copyright laws that permit making a copy of a copyrighted work for personal use. Including works that you borrow from friends. And allow your friend to make the copy on your behalf. Including over the Internet. Including over the peer 2 peer network du jour. In the Netherlands, this is (IIRC) allowed for all works, with the exception of computer software.
``For CISC you need more bytes per instruction, because there are more instructions.''
Not quite. In addition to having more complex instructions than RISC CPUs, CISC CPUs typically also have less regular instruction encoding than RISC CPUs. For example, on traditional MIPS (the canonical example of RISC), every instruction is 32 bits. On x86, at some point, instruction length varied from 8 to 120 bits. Many of the more commonly used instructions fit in 8 to 24 bits. In other words, these instructions are actually _smaller_ than those of the MIPS. This is actually the main contributing factor to smaller code size on x86 vs. MIPS.
There are also two factors that mitigate MIPS code size, compared to x86 code size: having 3 operands instead of 2, and having more registers. On MIPS, typical instructions have 3 operands: two sources and a destination. On x86, typical instructions have 2 operands: one that is used as both a source and a destination, and one that is only used as a source. But the real kicker is the number of registers: x86 has about 6 general purpose registers, whereas MIPS has about 30. The result is that, on MIPS, many operations are performed directly on registers (function arguments, local variables, temporaries) which on x86 are performed on memory locations (relative to the stack pointer or frame pointer). In other words, MIPS can usually say "set register x to register y plus register z", where x86 would say "load the value at frame pointer + 4 into eax, add the value at frame pointer - 8 to eax, store the result at frame pointer + 24". That's not only more instructions, but also involves 3 memory accesses, which are (on average) slower than register accesses.
``There is a strong disconnect between the way SQL represents data and the way traditional programming languages do.''
I agree, but...
``While we've come up with some clever solutions like ORM to alleviate the problem,''
I don't think ORM alleviates the problem so much as entrenches it. The classes-and-instances object model and the relational model are different, but can be expressed in one another. Object-relational mapping makes this easy by pretending the models are the same, and doing the mapping behind the scenes. This works for some cases, but if you want to get the best performance, you have to express things in a way that takes into account the efficiency considerations of the actual implementation. With ORM, you run into the situation where what is most succinct to express in code is not necessarily what is most efficient in terms of disk access and network resource usage. So, for efficiency reasons, you end up breaking the abstractions that your ORM provided...
``why not just store the data directly without any mapping?''
There isn't really such a thing as "without any mapping". However, you can ensure that the constructs your API provides are equivalent to what you can efficiently fetch or store in your data store. Since typical RDBMSs are usually optimized to execute typical SQL queries efficiently, SQL is actually a fairly good starting point. You can optimize this by creating indices to speed up common operations, and by tuning your RDBMS to speed up common operations. And, no doubt, you can do even better by creating custom shortcuts for specific needs of your application.
This is sort of what so-called NoSQL databases do: they are optimized for specific scenarios, and thus may outperform stock RDBMSs that are optimized for "we don't know what you want to do, so we try to make everything reasonably fast". It's also worth noting that NoSQL systems often return stale data or even allow inconsistencies in order to improve performance. By contrast, the strength of a good relational database is preserving the integrity of your data no matter what happens. Different tools for different jobs - or at least, different optimizations for different scenarios.
``You do realise that you can use h.264 for free for most uses? And if you don't qualify for free, the prices are practically trivial at the scale of business you'd have to be engaged in to require licensing? Apparently not.''
Yes, I do realize that. In fact, I made a statement about that in my previous post: MPEG-LA is offering this "free for most uses" licensing. I am sorry if that wasn't clear enough.
Of course, the reason MPEG-LA is offering "free for most uses" licensing is that more burdensome licensing would be a quick way to lose the standardization race.
``And the difference isn't just "slightly better", but massively better.''
I'll take your word for it. Still, I think all of H.264, Theora, and WebM offer better video quality at a given bitrate than H.263, which is or was widely considered good enough.
``There is no hardware support for WebM, for example.''
Again, I'll take your word for it. But I don't really get this argument. There was a time at which there was no hardware support for H.264, too. And a time when there wasn't hardware support for H.263. And a time when there wasn't hardware support for DivX. And even a time when there wasn't hardware support for MP3. All these formats have nevertheless gone on to be very popular, and have eventually received hardware support. The same could happen to WebM.
Also, you mentioned hardware support right after you claimed that H.264 was "massively better" than WebM. I don't know if you meant to imply that hardware support makes the format better, but if you did, you are not using "better" in the same sense I was. I was talking about "better video quality" (at a given bitrate), which is orthogonal to hardware support.
I hope that clarifies some possible misunderstandings. Also, to make it perfectly clear: I am not arguing that WebM is a better format than H.264, or even as good. I'm also not saying that H.264 is better. I am saying that, for pragmatic reasons, I prefer licensing that gives me more freedom and less hassle, and that if you want to standardize on something, the less burdensome it is to interested parties, the better.
``Give us a reasonable set of numbers. This A-D is a bullshit, a marketers' dream, but it's a pure, unadulterated insult to the people of the US.
Keep this up, it won't be long before our children start migrating to Asia and Europe for better life.''
In Europe, we already have letter grades for energy efficiency.
And they make little sense to me, at least how they have been implemented in the Netherlands: a C or D rating means your car is about as energy efficient as others _in its class_, A is best and means at least 20% more efficient, and G is worst and means at least 30% less efficient. But note the "in its class" part. You get tax credit based on the label, which means you can get more tax credit for buying, say, an A-label SUV instead of a C-label sedan, even if the sedan is more energy efficient.
``I'm generally in the "fuck copying Europe" camp''
I have to wonder why. Sounds like you actually want to do things differently just to avoid doing the same thing as something else. I don't see the point of that. By the way, did you know people in Europe breathe?
``Gas and Diesel cars should be rated in gallons/100 miles, and electric/hybrid cars should be given an equivalent assuming that the power comes from a modern coal plant delivered to San Diego.... Of course, the activists won't go for that, because they'll be forced to admit that their precious cars pollute arizona instead of socal.''
There's another very good reason for not going with that, and that's that it's simply not true. The coal plant may be somewhere else, or the electricity may come from a hydro dam instead, or even from a solar array in the car owner's own garden. I'm all for a common metric for energy consumption, but let's do it right instead of going with a metric based on hand waving and assumptions that are nearly always incorrect.
``Nobody knows what a newton or erg is, so Newtons are absolutely useless. However, we know how much energy is in a gallon of gasoline... roughly a gallon of gasoline.''
But that's only a matter of what you're used to. Over where I live, people don't know what a Newton, erg, _or_ gallon is. However, they do have electricity meters that display kWh, and get billed based on that. It's a perfectly usable unit for expressing energy, and is being applied to electric cars already. It could just as easily be applied to gasoline and diesel cars, but I don't know if that's really necessary. After all, we don't currently express gasoline and diesel in a common unit of energy, either (a given volume of gasoline contains less energy than the same volume of diesel).
Anyway, I see no problem with kWh (or Joules, for my part) being used as a unit of power for electric vehicles. The environmental impact, of course, depends on the source and mode of transport of the electricity, much like the environmental impact of a unit of gasoline depends on the source of the oil, the refining process, and the mode of transport. And the distance you can drive on a given amount of energy depends on the efficiency of your vehicle, your driving style, and the weather. You can try to capture all of these in a single "equivalent number of gallons of gasoline", but that's a rule of thumb at best.
``I don't care as much about the codecs being open source or closed source - I'm mainly interested in which format offers the higher quality at the same (or lower) bitrate.''
I, too, care about which format offers the higher quality at the same (or lower) bitrate. But I'm pragmatic enough to not want to have to jump through hoops if I want to install the software on my computer (on whatever OS I happen to be running), fix any bugs that I encounter while using it, or maybe even audit the software. And I don't want to get in trouble with the law over watching or encoding a video.
If MPEG-LA or any other organization wants to offer a video format that I cannot legally use, or for which a codec that allows me to do all the things I want cannot legally be implemented and distributed, that's fine with me. However, I then won't be using the format. Getting slightly better video quality isn't worth the hassle, annoyance, and security risks of typical "we care more about our anti-piracy measures than about our customers" software. If anyone else does want to use such software, fine by me.
The only point where this becomes a problem is when we are talking about standardizing on a format. Standardizing on a format that is not free to implement and use is a very bad idea. Not because it cannot be made to work, but because of pragmatic reasons: there will be barriers, and those barriers will hinder implementation and adoption. All the major players including MPEG-LA recognize this. That's why MPEG-LA is offering this "free for the most common uses" licensing: without that, H.264 would be a huge hassle. Similarly, Flash only became as widespread as it is because the player is freely available for the most popular platforms, TrueType won out over Type1 because of better licensing conditions, and free software is all over the software development world because you can use it without having to jump through hoops.
Ask yourself this: being pragmatic, how much are you willing to pay and how much work are you prepared to do to get to (legally) use H.265, the new and wonderful (and at this point, hypothetic) video format that is even better than H.264? At what point would you, for pragmatic reasons, decide to go with VP12, the (also hypothetic) video format that is almost as good, and free for all to use for any purpose, with free software codecs that you can install with a single click or command?
Also, you are correct that POSIX-compatible isn't necessarily very useful. It very much depends on which parts of POSIX have been implemented, and which versions. Some POSIX-compatible systems look quite unlike a traditional Unix system (e.g. many embedded OSes that may, for example, not support multiple processes), and POSIX APIs do not necessarily result in working programs (e.g. on OpenVMS, where POSIX calls cannot necessarily access every type of file). These systems may be POSIX-compliant and even certified, but that doesn't mean software written to the POSIX APIs will work and do what you want.
``Got to say this isn't surprising at all. Windows has never favored the dual boot setup. In the mind of Microsoft, there product should be the only one to touch the drive and thats it.''
But they do have a bootloader. It even has a menu. Also, Windows isn't really the problem here, other than apparently allowing applications to write to disk sectors that don't belong to them. But then, *nix systems allow that, too, for programs that have write access to the block device; e.g. applications running as root.
``Much like the Linux audio subsystems, it's a tail of throwing out something that works for 90% of users, replacing it with something of dubious virtue''
Which, I agree with you, is a Bad Thing.
However, to provide a counterpoint, for me, GRUB was the successor to LILO. LILO always struck me as very fragile, and at least at the time wasn't very featureful. By contrast, GRUB is the most reliable and most convenient boot loader I've ever used, and I've used it to repair many a broken system (*cough* programs overwriting the MBR without asking *cough*). To me, GRUB was a great improvement, and all distros I've ever used also offered LILO as an alternative, which I have ended up using on some systems where GRUB wouldn't work. I don't know what you were using instead of GRUB, but, for me, distros picking up GRUB did not break anything (because I could always use LILO instead) and brought a lot of improvement.
This contrary to the audio subsystems story, where I was perfectly satisfied with OSS until I had to switch to ALSA because OSS didn't have a driver for my sound card, and I'm still now using ALSA. The switch to ALSA didn't break anything for me besides some programs I had configured to use OSS (and ALSA OSS emulation not working), but I know the story is different for other people. And PulseAudio, from what I hear, has been a disaster. I wouldn't know, as I haven't used it yet.
``The problem is nobody owns it. This is what got GRUB developers in trouble. It is just there as an artifact of aligning first partition to full cylinder. Which is not requirement either, fdisk just did it so then everyone else followed. Since nobody owns it and it is not specified anywhere it has become free for all to mess with it. And hilarity ensued.''
Right.
Unlike many other posters of this thread, however, I think there is something to be said for using the entire space before the first partition (can be one sector, can be multiple cylinders) for the boot loader. There is simply only so much code you can put in the MBR, and although you can implement support for FAT (at least FAT12 and FAT16) there, I wouldn't expect the same to be true for other filesystems. Support for such filesystems needs to go somewhere, so why not in a "boot area"?
Of course, if you want to expect something to work, it needs to be specified, so there would need to be a standard for it. Perhaps the MBR could be extended with a description of the boot area (and, probably, a magic number to indicate the presence of this information), or perhaps the description and magic numbers could be put in the newly defined boot area itself.
The way GRUB has done this has always been a hack and has not always worked. Having said that, GRUB is the most featureful, convenient, and _reliable_ boot loader I have ever used, so I think they've done a good job. Bootstrapping a PC is hacky business, anyway.
``They are great to have, much more convenient. But not strictly required due to the way that hardware *is*. I run a straight linux box. And the last I checked, you could "dd" the kernel image directly to the first bootable device, usually/dev/hda or/dev/sda, and it would boot.''
That's really because Linux contains a (primitive) boot loader.
``Isn't it about time we had the Linux, Windows, and OS X guys sit down and agree on a standard for booting into multiple Operating Systems''
GRUB actually did invent and document a proposed standard: Multiboot. Alas, last I checked, none of Windows, OS X, Linux, FreeBSD, NetBSD and OpenBSD implemented it.
Ever since I heard radioactive decay mentioned as a true random process, I have wondered how long it would take until we figured out that it wasn't true random, after all. This story sounds like we may be getting closer.
``I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it.''
I couldn't agree more. Now that most programmers I know have moved on from languages with broken type systems and manual memory management, one of the few recurring issues I see in every project is time. Time zones, in particular, often aren't specified, or not picked up by people reading the specification. Same goes for time formats. And then there are people who forget to arrange for their clocks to be synchronized with the rest of the world, leading to wildly incorrect system times. It's almost a given that exchanging time information will cause trouble.
And that's without getting into the _actually_ difficult stuff, such as adding a number of years to a time format expressed as a number of seconds, or implementing a program that will perform some computation periodically, without drifting away from synchronized time.
``Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases.''
That just means that the software contains invalid assumptions. And, in this case, it seems to me that it was quite poorly worked out. Time being off by a second causes the system to reboot? I don't think that's what the customers ordered.
``Letting people onto a highway that is backed up for 62+ miles is just irresponsible. Then again, this is China. Not that the government is entirely evil, but they don't have a track record of always looking out for their citizens best interests.''
Maybe the government have decided to go libertarian and let people fend for themselves.
I think it's a pity that South Korea decided to block access to these North Korean outlets. Even if North Korea doesn't give its citizens the same benefits, I would imagine it helps to know what people on the other side are saying and are being told. More knowledge and understanding is a Good Thing, particularly when it comes to avoiding and resolving conflicts.
``Sounds more controlling/keep track than anything else.''
I don't know what id would be for, _other_ than for tracking people.
The problem I have with the RFID chips is that, now, you can be tracked not only when you show your passport (or other id) to someone, but also without your consent or knowledge. Regardless of the official statements, these chips can be and have been read from meters away.
You have that right. Letting people know how to use the chip would compromise security, you see. Don't believe the people who say the chip has already been broken. These weren't officially tasked to do so by the government, so their results don't count. Also, why are you asking questions about this in the first place? Do you want the boogeymen to win? This is for your own safety, man! How could you be against that?
``It is important that technology-minded users learn not to apply the usual centralist approach to everything. We are not cattle.''
We are not? Then why do we let ourselves be herded and look to the herders for our every need, including a sense of safety and comfort?
Note that by "we" I mean the general population. It doesn't necessarily apply to you, or even to me. But new tracking measures are being rolled out, and I don't see a lot of people making a fuss about it - rather, I see a lot of people being in favor.
Slashdot Mirror
``Nothing less than to abolish copyright will do.''
I wish you good luck in your quest, but I won't be marching with you all the way. I am quite fond of my copyleft licenses, myself.
``
Fuck that. I don't infringe copyright. Don't steal my money.''
While I agree that it isn't fair to make you pay for something you don't use, I still think there is something to this proposal. Consider the alternatives. One alternative I am aware of is the system as implemented in the USA: distributing copyrighted works without permission is illegal, but still widespread. In response, increasingly draconian measures are being instated by the government, and being accused of distributing or obtaining copyrighted works without permission leads to either high court fees, or high settlement payments. Moreover, government resources are used in at least some copyright cases. Is that the society you want to live in? Remember, all those things affect you, too, even if you (like me) don't participate in unauthorized copying of copyrighted works.
I realize that proposed-brazillian-system vs. actual-US-system is a false dichotomy, so if you can find an alternative that is better than either, especially if there is a chance that it will actually be implemented, I would like to hear about that, too.
Some European Union member states (at least the Netherlands) have copyright laws that permit making a copy of a copyrighted work for personal use. Including works that you borrow from friends. And allow your friend to make the copy on your behalf. Including over the Internet. Including over the peer 2 peer network du jour. In the Netherlands, this is (IIRC) allowed for all works, with the exception of computer software.
s/world/word/
I fail it.
And slashdot fails it for not letting me post this amendment, even after what's definitely more than one minute.
Let me bounce that back to you. Why do you want to change the world, just because it has been in use for a while?
``For CISC you need more bytes per instruction, because there are more instructions.''
Not quite. In addition to having more complex instructions than RISC CPUs, CISC CPUs typically also have less regular instruction encoding than RISC CPUs. For example, on traditional MIPS (the canonical example of RISC), every instruction is 32 bits. On x86, at some point, instruction length varied from 8 to 120 bits. Many of the more commonly used instructions fit in 8 to 24 bits. In other words, these instructions are actually _smaller_ than those of the MIPS. This is actually the main contributing factor to smaller code size on x86 vs. MIPS.
There are also two factors that mitigate MIPS code size, compared to x86 code size: having 3 operands instead of 2, and having more registers. On MIPS, typical instructions have 3 operands: two sources and a destination. On x86, typical instructions have 2 operands: one that is used as both a source and a destination, and one that is only used as a source. But the real kicker is the number of registers: x86 has about 6 general purpose registers, whereas MIPS has about 30. The result is that, on MIPS, many operations are performed directly on registers (function arguments, local variables, temporaries) which on x86 are performed on memory locations (relative to the stack pointer or frame pointer). In other words, MIPS can usually say "set register x to register y plus register z", where x86 would say "load the value at frame pointer + 4 into eax, add the value at frame pointer - 8 to eax, store the result at frame pointer + 24". That's not only more instructions, but also involves 3 memory accesses, which are (on average) slower than register accesses.
``There is a strong disconnect between the way SQL represents data and the way traditional programming languages do.''
I agree, but ...
``While we've come up with some clever solutions like ORM to alleviate the problem,''
I don't think ORM alleviates the problem so much as entrenches it. The classes-and-instances object model and the relational model are different, but can be expressed in one another. Object-relational mapping makes this easy by pretending the models are the same, and doing the mapping behind the scenes. This works for some cases, but if you want to get the best performance, you have to express things in a way that takes into account the efficiency considerations of the actual implementation. With ORM, you run into the situation where what is most succinct to express in code is not necessarily what is most efficient in terms of disk access and network resource usage. So, for efficiency reasons, you end up breaking the abstractions that your ORM provided ...
``why not just store the data directly without any mapping?''
There isn't really such a thing as "without any mapping". However, you can ensure that the constructs your API provides are equivalent to what you can efficiently fetch or store in your data store. Since typical RDBMSs are usually optimized to execute typical SQL queries efficiently, SQL is actually a fairly good starting point. You can optimize this by creating indices to speed up common operations, and by tuning your RDBMS to speed up common operations. And, no doubt, you can do even better by creating custom shortcuts for specific needs of your application.
This is sort of what so-called NoSQL databases do: they are optimized for specific scenarios, and thus may outperform stock RDBMSs that are optimized for "we don't know what you want to do, so we try to make everything reasonably fast". It's also worth noting that NoSQL systems often return stale data or even allow inconsistencies in order to improve performance. By contrast, the strength of a good relational database is preserving the integrity of your data no matter what happens. Different tools for different jobs - or at least, different optimizations for different scenarios.
``You do realise that you can use h.264 for free for most uses? And if you don't qualify for free, the prices are practically trivial at the scale of business you'd have to be engaged in to require licensing? Apparently not.''
Yes, I do realize that. In fact, I made a statement about that in my previous post: MPEG-LA is offering this "free for most uses" licensing. I am sorry if that wasn't clear enough.
Of course, the reason MPEG-LA is offering "free for most uses" licensing is that more burdensome licensing would be a quick way to lose the standardization race.
``And the difference isn't just "slightly better", but massively better.''
I'll take your word for it. Still, I think all of H.264, Theora, and WebM offer better video quality at a given bitrate than H.263, which is or was widely considered good enough.
``There is no hardware support for WebM, for example.''
Again, I'll take your word for it. But I don't really get this argument. There was a time at which there was no hardware support for H.264, too. And a time when there wasn't hardware support for H.263. And a time when there wasn't hardware support for DivX. And even a time when there wasn't hardware support for MP3. All these formats have nevertheless gone on to be very popular, and have eventually received hardware support. The same could happen to WebM.
Also, you mentioned hardware support right after you claimed that H.264 was "massively better" than WebM. I don't know if you meant to imply that hardware support makes the format better, but if you did, you are not using "better" in the same sense I was. I was talking about "better video quality" (at a given bitrate), which is orthogonal to hardware support.
I hope that clarifies some possible misunderstandings. Also, to make it perfectly clear: I am not arguing that WebM is a better format than H.264, or even as good. I'm also not saying that H.264 is better. I am saying that, for pragmatic reasons, I prefer licensing that gives me more freedom and less hassle, and that if you want to standardize on something, the less burdensome it is to interested parties, the better.
``Give us a reasonable set of numbers. This A-D is a bullshit, a marketers' dream, but it's a pure, unadulterated insult to the people of the US.
Keep this up, it won't be long before our children start migrating to Asia and Europe for better life.''
In Europe, we already have letter grades for energy efficiency.
And they make little sense to me, at least how they have been implemented in the Netherlands: a C or D rating means your car is about as energy efficient as others _in its class_, A is best and means at least 20% more efficient, and G is worst and means at least 30% less efficient. But note the "in its class" part. You get tax credit based on the label, which means you can get more tax credit for buying, say, an A-label SUV instead of a C-label sedan, even if the sedan is more energy efficient.
``I'm generally in the "fuck copying Europe" camp''
I have to wonder why. Sounds like you actually want to do things differently just to avoid doing the same thing as something else. I don't see the point of that. By the way, did you know people in Europe breathe?
``Gas and Diesel cars should be rated in gallons/100 miles, and electric/hybrid cars should be given an equivalent assuming that the power comes from a modern coal plant delivered to San Diego. ... Of course, the activists won't go for that, because they'll be forced to admit that their precious cars pollute arizona instead of socal.''
There's another very good reason for not going with that, and that's that it's simply not true. The coal plant may be somewhere else, or the electricity may come from a hydro dam instead, or even from a solar array in the car owner's own garden. I'm all for a common metric for energy consumption, but let's do it right instead of going with a metric based on hand waving and assumptions that are nearly always incorrect.
``Nobody knows what a newton or erg is, so Newtons are absolutely useless. However, we know how much energy is in a gallon of gasoline ... roughly a gallon of gasoline.''
But that's only a matter of what you're used to. Over where I live, people don't know what a Newton, erg, _or_ gallon is. However, they do have electricity meters that display kWh, and get billed based on that. It's a perfectly usable unit for expressing energy, and is being applied to electric cars already. It could just as easily be applied to gasoline and diesel cars, but I don't know if that's really necessary. After all, we don't currently express gasoline and diesel in a common unit of energy, either (a given volume of gasoline contains less energy than the same volume of diesel).
Anyway, I see no problem with kWh (or Joules, for my part) being used as a unit of power for electric vehicles. The environmental impact, of course, depends on the source and mode of transport of the electricity, much like the environmental impact of a unit of gasoline depends on the source of the oil, the refining process, and the mode of transport. And the distance you can drive on a given amount of energy depends on the efficiency of your vehicle, your driving style, and the weather. You can try to capture all of these in a single "equivalent number of gallons of gasoline", but that's a rule of thumb at best.
``I don't care as much about the codecs being open source or closed source - I'm mainly interested in which format offers the higher quality at the same (or lower) bitrate.''
I, too, care about which format offers the higher quality at the same (or lower) bitrate. But I'm pragmatic enough to not want to have to jump through hoops if I want to install the software on my computer (on whatever OS I happen to be running), fix any bugs that I encounter while using it, or maybe even audit the software. And I don't want to get in trouble with the law over watching or encoding a video.
If MPEG-LA or any other organization wants to offer a video format that I cannot legally use, or for which a codec that allows me to do all the things I want cannot legally be implemented and distributed, that's fine with me. However, I then won't be using the format. Getting slightly better video quality isn't worth the hassle, annoyance, and security risks of typical "we care more about our anti-piracy measures than about our customers" software. If anyone else does want to use such software, fine by me.
The only point where this becomes a problem is when we are talking about standardizing on a format. Standardizing on a format that is not free to implement and use is a very bad idea. Not because it cannot be made to work, but because of pragmatic reasons: there will be barriers, and those barriers will hinder implementation and adoption. All the major players including MPEG-LA recognize this. That's why MPEG-LA is offering this "free for the most common uses" licensing: without that, H.264 would be a huge hassle. Similarly, Flash only became as widespread as it is because the player is freely available for the most popular platforms, TrueType won out over Type1 because of better licensing conditions, and free software is all over the software development world because you can use it without having to jump through hoops.
Ask yourself this: being pragmatic, how much are you willing to pay and how much work are you prepared to do to get to (legally) use H.265, the new and wonderful (and at this point, hypothetic) video format that is even better than H.264? At what point would you, for pragmatic reasons, decide to go with VP12, the (also hypothetic) video format that is almost as good, and free for all to use for any purpose, with free software codecs that you can install with a single click or command?
Also, you are correct that POSIX-compatible isn't necessarily very useful. It very much depends on which parts of POSIX have been implemented, and which versions. Some POSIX-compatible systems look quite unlike a traditional Unix system (e.g. many embedded OSes that may, for example, not support multiple processes), and POSIX APIs do not necessarily result in working programs (e.g. on OpenVMS, where POSIX calls cannot necessarily access every type of file). These systems may be POSIX-compliant and even certified, but that doesn't mean software written to the POSIX APIs will work and do what you want.
``Got to say this isn't surprising at all. Windows has never favored the dual boot setup. In the mind of Microsoft, there product should be the only one to touch the drive and thats it.''
But they do have a bootloader. It even has a menu. Also, Windows isn't really the problem here, other than apparently allowing applications to write to disk sectors that don't belong to them. But then, *nix systems allow that, too, for programs that have write access to the block device; e.g. applications running as root.
``Much like the Linux audio subsystems, it's a tail of throwing out something that works for 90% of users, replacing it with something of dubious virtue''
Which, I agree with you, is a Bad Thing.
However, to provide a counterpoint, for me, GRUB was the successor to LILO. LILO always struck me as very fragile, and at least at the time wasn't very featureful. By contrast, GRUB is the most reliable and most convenient boot loader I've ever used, and I've used it to repair many a broken system (*cough* programs overwriting the MBR without asking *cough*). To me, GRUB was a great improvement, and all distros I've ever used also offered LILO as an alternative, which I have ended up using on some systems where GRUB wouldn't work. I don't know what you were using instead of GRUB, but, for me, distros picking up GRUB did not break anything (because I could always use LILO instead) and brought a lot of improvement.
This contrary to the audio subsystems story, where I was perfectly satisfied with OSS until I had to switch to ALSA because OSS didn't have a driver for my sound card, and I'm still now using ALSA. The switch to ALSA didn't break anything for me besides some programs I had configured to use OSS (and ALSA OSS emulation not working), but I know the story is different for other people. And PulseAudio, from what I hear, has been a disaster. I wouldn't know, as I haven't used it yet.
``The problem is nobody owns it. This is what got GRUB developers in trouble. It is just there as an artifact of aligning first partition to full cylinder. Which is not requirement either, fdisk just did it so then everyone else followed.
Since nobody owns it and it is not specified anywhere it has become free for all to mess with it. And hilarity ensued.''
Right.
Unlike many other posters of this thread, however, I think there is something to be said for using the entire space before the first partition (can be one sector, can be multiple cylinders) for the boot loader. There is simply only so much code you can put in the MBR, and although you can implement support for FAT (at least FAT12 and FAT16) there, I wouldn't expect the same to be true for other filesystems. Support for such filesystems needs to go somewhere, so why not in a "boot area"?
Of course, if you want to expect something to work, it needs to be specified, so there would need to be a standard for it. Perhaps the MBR could be extended with a description of the boot area (and, probably, a magic number to indicate the presence of this information), or perhaps the description and magic numbers could be put in the newly defined boot area itself.
The way GRUB has done this has always been a hack and has not always worked. Having said that, GRUB is the most featureful, convenient, and _reliable_ boot loader I have ever used, so I think they've done a good job. Bootstrapping a PC is hacky business, anyway.
``They are great to have, much more convenient. But not strictly required due to the way that hardware *is*. I run a straight linux box. And the last I checked, you could "dd" the kernel image directly to the first bootable device, usually /dev/hda or /dev/sda, and it would boot.''
That's really because Linux contains a (primitive) boot loader.
``Isn't it about time we had the Linux, Windows, and OS X guys sit down and agree on a standard for booting into multiple Operating Systems''
GRUB actually did invent and document a proposed standard: Multiboot.
Alas, last I checked, none of Windows, OS X, Linux, FreeBSD, NetBSD and OpenBSD implemented it.
Ever since I heard radioactive decay mentioned as a true random process, I have wondered how long it would take until we figured out that it wasn't true random, after all. This story sounds like we may be getting closer.
``I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it.''
I couldn't agree more. Now that most programmers I know have moved on from languages with broken type systems and manual memory management, one of the few recurring issues I see in every project is time. Time zones, in particular, often aren't specified, or not picked up by people reading the specification. Same goes for time formats. And then there are people who forget to arrange for their clocks to be synchronized with the rest of the world, leading to wildly incorrect system times. It's almost a given that exchanging time information will cause trouble.
And that's without getting into the _actually_ difficult stuff, such as adding a number of years to a time format expressed as a number of seconds, or implementing a program that will perform some computation periodically, without drifting away from synchronized time.
``Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases.''
That just means that the software contains invalid assumptions. And, in this case, it seems to me that it was quite poorly worked out. Time being off by a second causes the system to reboot? I don't think that's what the customers ordered.
``Letting people onto a highway that is backed up for 62+ miles is just irresponsible. Then again, this is China. Not that the government is entirely evil, but they don't have a track record of always looking out for their citizens best interests.''
Maybe the government have decided to go libertarian and let people fend for themselves.
I think it's a pity that South Korea decided to block access to these North Korean outlets. Even if North Korea doesn't give its citizens the same benefits, I would imagine it helps to know what people on the other side are saying and are being told. More knowledge and understanding is a Good Thing, particularly when it comes to avoiding and resolving conflicts.
``Sounds more controlling/keep track than anything else.''
I don't know what id would be for, _other_ than for tracking people.
The problem I have with the RFID chips is that, now, you can be tracked not only when you show your passport (or other id) to someone, but also without your consent or knowledge. Regardless of the official statements, these chips can be and have been read from meters away.
You have that right. Letting people know how to use the chip would compromise security, you see. Don't believe the people who say the chip has already been broken. These weren't officially tasked to do so by the government, so their results don't count. Also, why are you asking questions about this in the first place? Do you want the boogeymen to win? This is for your own safety, man! How could you be against that?
``It is important that technology-minded users learn not to apply the usual centralist approach to everything. We are not cattle.''
We are not? Then why do we let ourselves be herded and look to the herders for our every need, including a sense of safety and comfort?
Note that by "we" I mean the general population. It doesn't necessarily apply to you, or even to me. But new tracking measures are being rolled out, and I don't see a lot of people making a fuss about it - rather, I see a lot of people being in favor.