I think they should go for a new franchise. I'm thinking of "Nazi Bastard", the game that's exactly like its title. Think of a crossover between a random WW2 FPS and Postal. The story would be epic^H^H^H^H par for the course for a WW2 game: You are a nazi and a bastard. In fact, you're considered a huge asshole even by the worst the nazis have to offer. You shoot and piss your way through the allied forces and kill their leaders - and then you march on Berlin and kill Hitler as well because you feel like it.
And then they release DLC playing in the modern age (because you're such an asshole even death won't touch you) and your mission is to kill the game's original dev team so management can create twenty shitty sequels without them whining about it.
Hey, great idea: We just have all the WW2 FPSes use the same multiplyer system! The gamers are going to love it when their Call of Jewry Holocaust survivor gets pissed to death by a Nazi Bastard Parashitter (one of the exciting NB multiplayer classes)! Of course the lobby system will ensure that you never know what kinds of players you will play against for extra excitement!
Of course I didn't read much of TFA. Then again, an article with comments like "While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket" can't be very objective. Yeah, you don't like the iPhone. We get it. Now can we please get a developer who isn't obviously biased to compare the two platforms? Or at least one who can hide his bias for more than three paragraphs?
For example, both Quicktime and WMP are set to open AVIs by default and can open AVI files. However, they can't open DivX AVI files without installing a special codec.
Which is why I explicitly mentioned having installed a codec pack. It's hardly a fault of the container format that the operating system doesn't ship with all codecs. Even if we lock the container to just one codec and the format was published before the OS went into feature freeze for the release there's still a good chance it wouldn't be included due to licensing issues (for example because the OS vendor doesn't want to license the codec for every copy of the OS they sell). Codec packs will always be a neccessity unless you use a player that uses its own set of codecs.
Sometimes it's because they're using slightly altered containers.
The standard is not at fault when people simply don't implement it correctly. "Slightly altered" usually means "violating the spec" and "working only by coincidence". Don't expect broken files to work.
I had to transcode the file from MP4 to MP4 using FFMPEG in order to get the thing to play. It's retarded.Which could be due to a slightly broken container or due to one of the used codecs using a feature your player doesn't understand. Welcome to the world of embedded media players. You can't easily standardize this away because we're once again at the baseline problem: Which current devices do you include, which do you exclude? What kind of processng power do you assume for ALL future devices? Because that's what your standard would enforce if successful.
An unwise choice might mean that even portable media players with a 3" screen must have enough processing power to decode 1080p video (which, actually, would preclude any success in the portable media market as such a strong processor would be unacceptable in terms of both heat and power consumption). However, if we set the bar lower the format becomes unusable for high-definition video, which will severly hamper its use in other markets. One-size-fits-all unfortunately doesn't work here because the requirements for the various use cases are disparate enough to be mutually exclusive in some cases.
Yeah, that might make sense if the problem were 1 specific player rather than an assortment of software players, software editors, and hardware devices which each use different incompatible variations and don't include support for other variations. Perhaps people would make a greater effort to standardize, then all the players, editors, and encoders could interoperate better.
On the software side I don't see many problems anymore. We had a bit of a mess during the DivX/XviD days but nowadays most sane people default to H.264 created with one of few well-known (and well-behaved) encoders. You do still see some other codecs around but those usually don't make much of a problem as well.
Hardware players... Yes. The problem with hardware players is that they often use trimmed-down decoders that only cater to the most common uses of the codec because a more full-featured implementation would be too slow on the tiny processor (or because the entire decoder is an ASIC and a bigger chip would have been too expensive). The result is that they can be very picky about what they take and what not. We could define some ultra-strict format for use with them but again we'd probably need to define several profiles for various kinds of devices as one size doesn't fit all. And it's unlikely that people are going to release their videos in six different formats, not to mention that many casual users aren't likely to know which profiles their device is going to support.
I think it's unrealistic to ask for one single format that works everywhere for everyone. The requirements are too different. A better idea would be to distribute the video in a high-quality format and make a program that can convert it to a format understood by your specific player. Yes, you need to spend ages reencoding everything but I think that's the closest we are going to get to "one size fits all".
And what's a "file type" then? What distinguishes one "file type" from another?
The magic number. In cases where that's ambiguous: The magic number and the data neccessary for a program to determine which of the possible types is the correct one. If we want to expand the definition a bit let's add possible metadata used to make a brief summary of the file's contents as delivered by the *nix program file, although that information technically doesn't differentiate between different kinds of file.
Having multiple different kinds of files using different types of encoding which might need to be viewed in different viewers, but all having the same extension and "file type" pretty well defeats the purpose.
Please give me an example of such a scenario. I have never encountered a special kind of MKV, AVI or other video file that I need to open in one specific media player that I don't use for most files of the same type. Certain file types that warrant a specific application, yes. But in those cases I always use the same program for that file type. (There is the case of self-extracting archives but they do warrant the.exe extension because they indeed are PE files and Windows determines executability based on the extension.)
Yes, there's your "my Playstation only plays certain codecs" case but remember that neither the Playstation nor the container format were designed for the use case of playing random media files on the Playstation. The container format was designed for use on PCs where it's reasonable to assume that a missing codec can be easily installed. Embedded systems (and yes, your PlayStation does count due to software restrictions) always suffer from limitations and it's not reasonable to assume that the rest of the world will limit themselves to their level just to indulge them.
Case in point: The iPod touch can only handle video in 320x480 resolution. Would you want to limit all video files to that resolution just so they can easily run on the iPod? No, you wouldn't. So why should everyone be restricted in which codecs and settings they can use, which all work perfectly fine on all devices the files are intended for so you can run them on certain embedded devices?
I already mentioned that one could make a pseudo-standard where you use a nonstandard file extension to denote files adhering to certain restrictions (eg. ones that you can play back on your PlayStation), which you refused because you absolutely insist that the container format shouldn't support other codecs and settings at all. By the way, what would we use as a baseline? What the PlayStation 3 supports? The XBox 360? The Wii? The Archos 7? Most likely your answer would boil down to "what fits my specific use case".
In the end you insist that container formats should be made to do things they were never intended to (deliver one specific audio and video codec each with specific parameters encoded in a specific way) just so you can more easily put files on your specific embedded player. Why not change the part that's causing the problem, the player? That doesn't require a whole industry standard to bend over backwards to support one specific device that, I might add, only came out recently. If that isn't possible for some reason, why not come up with a special file format for that device? you'll need to reencode all videos for the device but there won't be any ambiguity anymore.
And no, most users aren't confused by the fact that an AVI or MKV file might use H.264, DivX or Theora to encode video - they only care that it's a video file and that their media player of choice can play it back, which it can if they either use VLC or have installed a codec pack. And even if they care about the codec, the source of the video usually gives you some metadata. Whether you ripped the video yourself or got it off a torrent site, at some point you will have been presented with a piece of text that told you which codecs were involved. If you cared you wrote it down and if you didn't it's easy to determine it later; any media player can do that. Even for unknown codecs (although you'll have to google the FourCC).
But... but... that precludes future codecs from being used in ".mp3" files! Oh, right, that's totally not a problem, because we come up with new formats for the new codecs.
I know, I shouldn't be feeding trolls but please do read up on the terms "container" and "codec" and why the two aren't interchangable. MP3 files and MKV files serve fundamentally different purposes; they just happen to be used in similar scenarios.
We use the file extension to indicate the encoding so that we know whether a certain viewer will be able to display it.
No, we use the file extension to indicate the file type, which is something else. And even knowledge of the "encoding" (which does not mean what you think it does) only gives us vague clues as to whether a given device or program can open the file. This applies even to very simple formats like MP3 files (bitrate, samplerate, CBR/VBR, stereo encoding scheme and even the presence/absence of particular versions of ID3 tag can all influence that), Windows Bitmaps (may have one of six different color depths, may use of of several compression schemes, may use one of five different header types and may even be a wrapper for a JPEG or PNG image) and text files (try opening a file encoded with UTF-16, GB 18030 or CP 01047 with a program that only supports ASCII, which can happpen on an embedded device). This also applies to.xhtml, which may or may not contain JavaScript, MathML, SVG etc.
Few file formats contains only one thing that can be unambiguously identified just by looking at the file extension. You always need to look at what's inside and that may or may not be supported by all programs/devices using it. Modern BMP libraries might not be able to read OS/2 bitmap arrays. MP3 players can choke on a high-quality VBR MP3 as their hardware/firmware is not capable of decoding it - or they don't. Or maybe it's dependent on which encoder you used. It's actually impossible to tell without trying it out (or reading the review of someone who did). It might even change between firmware revisions.
From a users perspective, vendors are choosing to use the same extension for several similar but incompatible file formats for no apparent reason. If we want to do that, we may as well just give all video files the extension ".vid" and be done with it.
No, file extensions denote one thing very clearly: The file type. This is to tell the OS, not the user, how to read the file - and it's a Windows tradition. Do note that usage of file extensions was not always universal. For instance, Mac OS only really took up file extensions with OS X; prior to that files often just had associated metadata which was the primary means of identifying file type. File extensions are just an in-band way of transmitting metadata which is primarily meant for the device, not you. Note that Windows still hides known extensions by default. It doesn't do that to be mean, it does it because Microsoft assumes that the exact file type shouldn't matter to most users as long as they know it's a "text file" or a "video".
If you want easily accessible information about what exactly a given file contains (down to which codecs at which settings were used and which kinds of subtitles the file contains) you need to ask your OS vendor to include an overview of that in the file manager. Or ask whoever distributes the file to include proper metadata. Don't ask the developers of file formats to artificially restrict the capabilities of their formats because you can't be arsed to open the file in VLC and have a look at the stream inspector.
You're comparing apples to oranges. MP3 files can't contain anything but an MP3 stream and an optional ID3 header. The format was designed to contain MP3 streams, period. MKV, on the other hand, is a complete audio/video container format designed to support a variety of codecs.
If your media player says it supports MP3s and you try to play an MP3, it shouldn't tell you that you need to download a different MP3 codec.
You apparently never tried to use MP3s on mobile devices. Unless you use something with a smartphone-class processor to play them back you will have to conform to arbitrary restrictions like "no more than 192 kb/s", "no VBR" or even "not encoded with certain encoders". If you don't meet the criteria, the file might play back incorrectly or not at all because the decoder chip can't cope.
And when MPEG came up with AAC, people didn't continue to use the extension ".mp3" for it.
Of course not, because an MP3 file can't possibly contain an AAC stream.
When JPEG came up with a new incompatible graphics format, they didn't keep using ".jpg".
Of course, because.jpg files can't contain JPEG 2000 data. Do note, however, that.jpg files can contain either JIF, JFIF or JIF/JFIF+Exif data, all of which are, strictly speaking, incompatible with each other. Also, the data might be progressively encoded, which is not supported by every decoder; not to mention the obscure 12-bit JPEG.
I don't know what's so crazy about coming up with a standardized MPEG4 container that you can assume is H264, AAC, support for chapters, alternate audio, and subtitles, and leaving it at that.
You'd assume that the MPEG would have come up with such a format instead of relying on random external groups to do so. They did. It's called MPEG-4 Part 14 (more commonly known as.mp4).
So essentially your problem with Matroska is that they didn't develop a format specific to a certain codec when a format for that codec had already been developed and published and was completely orthogonal to what their project aimed to do. That's a bit like complaining that Tesla Motors didn't invent the road tractor: It was already there when their first product hit the street and it doesn't do what their products are all about.
You might try to convince the developers to come up with a pseudo-standard (like the various Zip derivatives) but they're unlikely to limit their container to an arbitrary subset of all codecs, especially since this precludes all future codecs from ever being used.
Such a pseudo-standard might say "files ending in.mv1 are Matroska (version V) files with exactly one video stream using codec A with resolutions R1, R2 or R3 and bitrates BR1, BR2 and BR3; one audio stream using codec B with sample rate SR and bitrate BR4; and any number of subtitles and chapter metadata". Future revisions would increment the number at the end. Add a fancy name to the new "standard" and sell that to device manufacturers. Might work, but only for devices which cater to the market you're aiming the "standard" at.
The whole thing doesn't doesn't work if a device simply doesn't support the specific resolutions required. Or the audio bitrate. Or has other restrictions the "standard" doesn't even touch on. For example, most PDS-sized devices are perfectly capable of playing back videos - as long as they have been scaled down to somewhere in the general vincinity of the device's screen size and use one of few supported codecs with specific parameters. And don't use certain features of the container. All of which vary from device to device.
Unless the device market becomes clearer and more uniform you will have to compare specific details of your file to the device's capabilities. Unless you want everyone to use H.264 with stereo AAC sound at 320x240 and 30 FPS. No subtitles, no surround sound, no high-res video. That's about the baseline.
The problem is that it's more complex than just "which video codec does this use?". Whether or not a device supports a given file can depend on the container, video and audio codecs, video and audio bitrates, video resolution etc. If you were to add an such information to the file extension you'd end up with file names like Transformers 3.h264-1080x1920-1200kbps.aac-44khz-128kbps.srt.srt.bmp.chapters.mkv. Informative but extremely unwieldy.
Well, MKV does have the larger feature set and is more widely supported. This would suggest that it's indeed better than Ogg unless its actual implementation is downright catastrophical.
I like how you immediately jumped to raping babies. Nobody was talking about rape or babies - in fact originally it was explicitly consensual sex with children. You prove the point by internally escalating the argument to its absurd extreme. In short, you are scaremongering.
You just made the GP's point: Pedophilia is anathema to the point of merely using it to illustrate a point is automatically considered to invalidate the point. It's the Hitler of sexuality* (mention it and the discussion stops being rational) and it automatically disables all higher reasoning in most people. Which is precisely because of social conditioning, given that various cultures practiced and in rare cases still practice it and saw/see nothing wrong with it.
So yes, pedophilia being abhorrent to most people is exactly the same as oral sex being abhorrent to some people. Even though one can make logically valid arguments as to why it's bad, most people immediately become irrational when it's mentioned and detest it because they are expected to do so. (Besides, the arguments against oral sex are also logically valid; they merely have some premises most people assume to be false.)
Note that I'm not defending pedophilia here. It's bad for a number of reasons but we need to stop kneejerking every time it's mentioned. All that does accomplish is to make it impossible for us to actually deal with the issue. We need to get rid of that berserk button.
* Does it count as a Godwin when I invoke Gowin's Law to illustrate a point?
Ugh. That "come up with a 1 M$ attack" should have read "come up with a 1 K$ attack". Devising an attack that costs ten times what you have and only damages 0.1% of your target is not a good plan.
Of course this depends on you being able to come up with a 1 M$ attack that can completely destroy the 1 G$ asset or at least cause about 1 M$ of damage per attack. Even if we go down to "the defender wants to avoid significant damage to the asset at all costs" your attacks need to inflict damage worth at least, say, 10 K$ per attack before you're even seen as a credible threat and not just a high-profile vandal.
If you can come up with a 1000 USD drone capable of obliterating even an office building with one shot I'll be damn impressed. I'll be impressed if your drone can even cause substantial damage to the building. Most likely the worst you can do is to crash through the window and detonate a hand grenade. That's bad but it doesn't warrant the defender to go all-out and lob the most expensive SAM on the market at your drone. Hardened windows are much more cost-effective.
Unfortunately that 500$ drone has all the destructive capability of a ten pound object smacking into you at a few dozen mph. For 1000$ you might get a drone capable of carrying and dropping a hand grenade.
Your DOS war would only work if you could convice the victim that a swarm of RC planes is a major threat on its own. Good luck with that.
Step 1: All kinds of important OSS developers from companies all over the world come to the USA for a conference.
Step 2: The developers are arrested for potential piracy.
Step 3: All kinds of companies pull out of the USA pronto and make sure to never book another conference there.
Step 4: The DHS gets buried in a class action lawsuit from every conference venue in the United States.
Step 5: The DHS sees no response but to incinerate the venues in the name of national security.
Step 6: More class action lawsuits as it turns out there were people in those venues.
Step 7: More security-vital incineration.
Step 8: The survivors band together to rent the DHS headquarters for a national security conference, which they attend.
Step 9: The DHS incinerates itself in the name of national security.
Step 10: Taliban.
Step 11: ????
Step 12: Profit.
But that's Java and therefore evil. And slow. Let's use JavaScript instead, which is wholesome and zippy. And because that doesn't allow closed-source games, let's instead use a Windows-only browser plugin. But because people don't want to install a plugin for each game let's just distribute our games through ActiveX! People are going to love it!
Yeah, at some point these efforts begin to look like a bad attempt at replicating JNLP.
Note that I explicitly asked for a single screen height/width ratio and a resolution-independent GUI. This would allow the vendors to select a screen of any size with a DPI of any size as long as it adheres to that ratio; at the same time all applications written to the spec would have working GUIs on all devices. This would make it much easier to write one app and have it target a significant part of the Android ecosystem.
Granted, this would only make sense if you split Android into several profiles (one for smartphones and PDAs, one for regular computers etc.) but it'd still be nice to be able to write one app and have it work on many devices, whether they're from Google, HTC or whoever else. I don't know how fragmented things are right now but in the worst case you need to start with research into which devices support which resolutions, how you need to design the GUI to be compatible with the most of them etc. Less work for the developers means a more attractive platform.
Of course it would be nice if Android would guarantee a certain screen height/width ratio. Coupled with a resolution-independent GUI that would make it trivial to build one GUI that works on every device (even if those with a particularly small screen might suffer from very small text).
Your remark about links is true but having links easily detectible does not preclude having them offer sdditional things upon hovering. Yes, links that do nonsense upon hovering are usually pointless but I don't see much of a better was to implement popup menus. We expect the menu header to be clickable beause it's a link. It usually represents something (a category) that has a page itself and repeating the header in the menu itself just so the header doesn't have to be a link isn't good design, either.
And just forgoing menus altogether is definitely not good design. If I have forty pages (eg. product lines) in six categories (eg. product types) most users don't want to see a list of forty-six links which they have to hunt through. If someone wants to know about my portable media players they don't want to wade through links to my premium sound systems. Overwhelming people with barely-structured options (and having all of them on the screen will look like bad structuring) is unlikely to keep them on the site.
Of course I could make people navigate to the category first and have them pick the product from there but this severely limits the speed at which they can explore the site. This can be enough to turn away people who don't know exactly where I put what they're looking for. If it takes someone ten page loads to find the product where it could take them one I'm clearly doing something wrong.
So what do we do? How do you implement a navigation that doesn't permanently keep all links on the screen yet doesn't require the user to load several different pages to get to their goal?
What I really hate about Idle is that if you use the Slashdot RSS feed it's impossible to distinguish between an Idle story and a regular one. You also can't filter out Idle.
I'm thinking about writing a web scraper that obtains the regular RSS feed, logs into/., grabs my filtered story list and uses that to sanitize the RSS feed, which is then presented to me.
Alternatively,/. could just offer a second RSS feed for those who are perfectly aware of xkcd, waterskiing squirrels and the like without reading about them on/..
Slashdot Mirror
I think they should go for a new franchise. I'm thinking of "Nazi Bastard", the game that's exactly like its title. Think of a crossover between a random WW2 FPS and Postal. The story would be epic^H^H^H^H par for the course for a WW2 game: You are a nazi and a bastard. In fact, you're considered a huge asshole even by the worst the nazis have to offer. You shoot and piss your way through the allied forces and kill their leaders - and then you march on Berlin and kill Hitler as well because you feel like it.
And then they release DLC playing in the modern age (because you're such an asshole even death won't touch you) and your mission is to kill the game's original dev team so management can create twenty shitty sequels without them whining about it.
Hey, great idea: We just have all the WW2 FPSes use the same multiplyer system! The gamers are going to love it when their Call of Jewry Holocaust survivor gets pissed to death by a Nazi Bastard Parashitter (one of the exciting NB multiplayer classes)! Of course the lobby system will ensure that you never know what kinds of players you will play against for extra excitement!
Of course I didn't read much of TFA. Then again, an article with comments like "While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket" can't be very objective. Yeah, you don't like the iPhone. We get it. Now can we please get a developer who isn't obviously biased to compare the two platforms? Or at least one who can hide his bias for more than three paragraphs?
Which is why I explicitly mentioned having installed a codec pack. It's hardly a fault of the container format that the operating system doesn't ship with all codecs. Even if we lock the container to just one codec and the format was published before the OS went into feature freeze for the release there's still a good chance it wouldn't be included due to licensing issues (for example because the OS vendor doesn't want to license the codec for every copy of the OS they sell). Codec packs will always be a neccessity unless you use a player that uses its own set of codecs.
The standard is not at fault when people simply don't implement it correctly. "Slightly altered" usually means "violating the spec" and "working only by coincidence". Don't expect broken files to work.
The magic number. In cases where that's ambiguous: The magic number and the data neccessary for a program to determine which of the possible types is the correct one. If we want to expand the definition a bit let's add possible metadata used to make a brief summary of the file's contents as delivered by the *nix program file, although that information technically doesn't differentiate between different kinds of file.
Please give me an example of such a scenario. I have never encountered a special kind of MKV, AVI or other video file that I need to open in one specific media player that I don't use for most files of the same type. Certain file types that warrant a specific application, yes. But in those cases I always use the same program for that file type. (There is the case of self-extracting archives but they do warrant the .exe extension because they indeed are PE files and Windows determines executability based on the extension.)
Yes, there's your "my Playstation only plays certain codecs" case but remember that neither the Playstation nor the container format were designed for the use case of playing random media files on the Playstation. The container format was designed for use on PCs where it's reasonable to assume that a missing codec can be easily installed. Embedded systems (and yes, your PlayStation does count due to software restrictions) always suffer from limitations and it's not reasonable to assume that the rest of the world will limit themselves to their level just to indulge them.
Case in point: The iPod touch can only handle video in 320x480 resolution. Would you want to limit all video files to that resolution just so they can easily run on the iPod? No, you wouldn't. So why should everyone be restricted in which codecs and settings they can use, which all work perfectly fine on all devices the files are intended for so you can run them on certain embedded devices?
I already mentioned that one could make a pseudo-standard where you use a nonstandard file extension to denote files adhering to certain restrictions (eg. ones that you can play back on your PlayStation), which you refused because you absolutely insist that the container format shouldn't support other codecs and settings at all. By the way, what would we use as a baseline? What the PlayStation 3 supports? The XBox 360? The Wii? The Archos 7? Most likely your answer would boil down to "what fits my specific use case".
In the end you insist that container formats should be made to do things they were never intended to (deliver one specific audio and video codec each with specific parameters encoded in a specific way) just so you can more easily put files on your specific embedded player. Why not change the part that's causing the problem, the player? That doesn't require a whole industry standard to bend over backwards to support one specific device that, I might add, only came out recently. If that isn't possible for some reason, why not come up with a special file format for that device? you'll need to reencode all videos for the device but there won't be any ambiguity anymore.
And no, most users aren't confused by the fact that an AVI or MKV file might use H.264, DivX or Theora to encode video - they only care that it's a video file and that their media player of choice can play it back, which it can if they either use VLC or have installed a codec pack. And even if they care about the codec, the source of the video usually gives you some metadata. Whether you ripped the video yourself or got it off a torrent site, at some point you will have been presented with a piece of text that told you which codecs were involved. If you cared you wrote it down and if you didn't it's easy to determine it later; any media player can do that. Even for unknown codecs (although you'll have to google the FourCC).
I know, I shouldn't be feeding trolls but please do read up on the terms "container" and "codec" and why the two aren't interchangable. MP3 files and MKV files serve fundamentally different purposes; they just happen to be used in similar scenarios.
No, we use the file extension to indicate the file type, which is something else. And even knowledge of the "encoding" (which does not mean what you think it does) only gives us vague clues as to whether a given device or program can open the file. This applies even to very simple formats like MP3 files (bitrate, samplerate, CBR/VBR, stereo encoding scheme and even the presence/absence of particular versions of ID3 tag can all influence that), Windows Bitmaps (may have one of six different color depths, may use of of several compression schemes, may use one of five different header types and may even be a wrapper for a JPEG or PNG image) and text files (try opening a file encoded with UTF-16, GB 18030 or CP 01047 with a program that only supports ASCII, which can happpen on an embedded device). This also applies to .xhtml, which may or may not contain JavaScript, MathML, SVG etc.
Few file formats contains only one thing that can be unambiguously identified just by looking at the file extension. You always need to look at what's inside and that may or may not be supported by all programs/devices using it. Modern BMP libraries might not be able to read OS/2 bitmap arrays. MP3 players can choke on a high-quality VBR MP3 as their hardware/firmware is not capable of decoding it - or they don't. Or maybe it's dependent on which encoder you used. It's actually impossible to tell without trying it out (or reading the review of someone who did). It might even change between firmware revisions.
No, file extensions denote one thing very clearly: The file type. This is to tell the OS, not the user, how to read the file - and it's a Windows tradition. Do note that usage of file extensions was not always universal. For instance, Mac OS only really took up file extensions with OS X; prior to that files often just had associated metadata which was the primary means of identifying file type. File extensions are just an in-band way of transmitting metadata which is primarily meant for the device, not you. Note that Windows still hides known extensions by default. It doesn't do that to be mean, it does it because Microsoft assumes that the exact file type shouldn't matter to most users as long as they know it's a "text file" or a "video".
If you want easily accessible information about what exactly a given file contains (down to which codecs at which settings were used and which kinds of subtitles the file contains) you need to ask your OS vendor to include an overview of that in the file manager. Or ask whoever distributes the file to include proper metadata. Don't ask the developers of file formats to artificially restrict the capabilities of their formats because you can't be arsed to open the file in VLC and have a look at the stream inspector.
Because everyone knows you get a better picture when you shine a light at the screen.
You apparently never tried to use MP3s on mobile devices. Unless you use something with a smartphone-class processor to play them back you will have to conform to arbitrary restrictions like "no more than 192 kb/s", "no VBR" or even "not encoded with certain encoders". If you don't meet the criteria, the file might play back incorrectly or not at all because the decoder chip can't cope.
Of course not, because an MP3 file can't possibly contain an AAC stream.
Of course, because .jpg files can't contain JPEG 2000 data. Do note, however, that .jpg files can contain either JIF, JFIF or JIF/JFIF+Exif data, all of which are, strictly speaking, incompatible with each other. Also, the data might be progressively encoded, which is not supported by every decoder; not to mention the obscure 12-bit JPEG.
You'd assume that the MPEG would have come up with such a format instead of relying on random external groups to do so. They did. It's called MPEG-4 Part 14 (more commonly known as .mp4).
So essentially your problem with Matroska is that they didn't develop a format specific to a certain codec when a format for that codec had already been developed and published and was completely orthogonal to what their project aimed to do. That's a bit like complaining that Tesla Motors didn't invent the road tractor: It was already there when their first product hit the street and it doesn't do what their products are all about.
You might try to convince the developers to come up with a pseudo-standard (like the various Zip derivatives) but they're unlikely to limit their container to an arbitrary subset of all codecs, especially since this precludes all future codecs from ever being used.
.mv1 are Matroska (version V) files with exactly one video stream using codec A with resolutions R1, R2 or R3 and bitrates BR1, BR2 and BR3; one audio stream using codec B with sample rate SR and bitrate BR4; and any number of subtitles and chapter metadata". Future revisions would increment the number at the end. Add a fancy name to the new "standard" and sell that to device manufacturers. Might work, but only for devices which cater to the market you're aiming the "standard" at.
Such a pseudo-standard might say "files ending in
The whole thing doesn't doesn't work if a device simply doesn't support the specific resolutions required. Or the audio bitrate. Or has other restrictions the "standard" doesn't even touch on. For example, most PDS-sized devices are perfectly capable of playing back videos - as long as they have been scaled down to somewhere in the general vincinity of the device's screen size and use one of few supported codecs with specific parameters. And don't use certain features of the container. All of which vary from device to device.
Unless the device market becomes clearer and more uniform you will have to compare specific details of your file to the device's capabilities. Unless you want everyone to use H.264 with stereo AAC sound at 320x240 and 30 FPS. No subtitles, no surround sound, no high-res video. That's about the baseline.
The problem is that it's more complex than just "which video codec does this use?". Whether or not a device supports a given file can depend on the container, video and audio codecs, video and audio bitrates, video resolution etc. If you were to add an such information to the file extension you'd end up with file names like Transformers 3.h264-1080x1920-1200kbps.aac-44khz-128kbps.srt.srt.bmp.chapters.mkv. Informative but extremely unwieldy.
Well, MKV does have the larger feature set and is more widely supported. This would suggest that it's indeed better than Ogg unless its actual implementation is downright catastrophical.
I like how you immediately jumped to raping babies. Nobody was talking about rape or babies - in fact originally it was explicitly consensual sex with children. You prove the point by internally escalating the argument to its absurd extreme. In short, you are scaremongering.
You just made the GP's point: Pedophilia is anathema to the point of merely using it to illustrate a point is automatically considered to invalidate the point. It's the Hitler of sexuality* (mention it and the discussion stops being rational) and it automatically disables all higher reasoning in most people. Which is precisely because of social conditioning, given that various cultures practiced and in rare cases still practice it and saw/see nothing wrong with it.
So yes, pedophilia being abhorrent to most people is exactly the same as oral sex being abhorrent to some people. Even though one can make logically valid arguments as to why it's bad, most people immediately become irrational when it's mentioned and detest it because they are expected to do so. (Besides, the arguments against oral sex are also logically valid; they merely have some premises most people assume to be false.)
Note that I'm not defending pedophilia here. It's bad for a number of reasons but we need to stop kneejerking every time it's mentioned. All that does accomplish is to make it impossible for us to actually deal with the issue. We need to get rid of that berserk button.
* Does it count as a Godwin when I invoke Gowin's Law to illustrate a point?
Ugh. That "come up with a 1 M$ attack" should have read "come up with a 1 K$ attack". Devising an attack that costs ten times what you have and only damages 0.1% of your target is not a good plan.
Of course this depends on you being able to come up with a 1 M$ attack that can completely destroy the 1 G$ asset or at least cause about 1 M$ of damage per attack. Even if we go down to "the defender wants to avoid significant damage to the asset at all costs" your attacks need to inflict damage worth at least, say, 10 K$ per attack before you're even seen as a credible threat and not just a high-profile vandal.
If you can come up with a 1000 USD drone capable of obliterating even an office building with one shot I'll be damn impressed. I'll be impressed if your drone can even cause substantial damage to the building. Most likely the worst you can do is to crash through the window and detonate a hand grenade. That's bad but it doesn't warrant the defender to go all-out and lob the most expensive SAM on the market at your drone. Hardened windows are much more cost-effective.
Who needs Stingers and Patriots? I want to see if they could hit a 500$ drone with a Minuteman.
Unfortunately that 500$ drone has all the destructive capability of a ten pound object smacking into you at a few dozen mph. For 1000$ you might get a drone capable of carrying and dropping a hand grenade.
Your DOS war would only work if you could convice the victim that a swarm of RC planes is a major threat on its own. Good luck with that.
Apparently IBM found a generic algorithm that can be applied to any problem. Sorting, filtering, traveling salesman...
Yeah. I mean, they totally ruined Magical Tea Party with the localization.
Er, I mean Hellspawn 2. Yeah. Definitely Hellspawn 2.
If I had a Facebook account I'd go and post: "I just finished my taxes with TurboTax and I'm getting a $-493 refund!"
Step 1: All kinds of important OSS developers from companies all over the world come to the USA for a conference.
Step 2: The developers are arrested for potential piracy.
Step 3: All kinds of companies pull out of the USA pronto and make sure to never book another conference there.
Step 4: The DHS gets buried in a class action lawsuit from every conference venue in the United States.
Step 5: The DHS sees no response but to incinerate the venues in the name of national security.
Step 6: More class action lawsuits as it turns out there were people in those venues.
Step 7: More security-vital incineration.
Step 8: The survivors band together to rent the DHS headquarters for a national security conference, which they attend.
Step 9: The DHS incinerates itself in the name of national security.
Step 10: Taliban.
Step 11: ????
Step 12: Profit.
But that's Java and therefore evil. And slow. Let's use JavaScript instead, which is wholesome and zippy. And because that doesn't allow closed-source games, let's instead use a Windows-only browser plugin. But because people don't want to install a plugin for each game let's just distribute our games through ActiveX! People are going to love it!
Yeah, at some point these efforts begin to look like a bad attempt at replicating JNLP.
Note that I explicitly asked for a single screen height/width ratio and a resolution-independent GUI. This would allow the vendors to select a screen of any size with a DPI of any size as long as it adheres to that ratio; at the same time all applications written to the spec would have working GUIs on all devices. This would make it much easier to write one app and have it target a significant part of the Android ecosystem.
Granted, this would only make sense if you split Android into several profiles (one for smartphones and PDAs, one for regular computers etc.) but it'd still be nice to be able to write one app and have it work on many devices, whether they're from Google, HTC or whoever else. I don't know how fragmented things are right now but in the worst case you need to start with research into which devices support which resolutions, how you need to design the GUI to be compatible with the most of them etc. Less work for the developers means a more attractive platform.
Of course it would be nice if Android would guarantee a certain screen height/width ratio. Coupled with a resolution-independent GUI that would make it trivial to build one GUI that works on every device (even if those with a particularly small screen might suffer from very small text).
Your remark about links is true but having links easily detectible does not preclude having them offer sdditional things upon hovering. Yes, links that do nonsense upon hovering are usually pointless but I don't see much of a better was to implement popup menus. We expect the menu header to be clickable beause it's a link. It usually represents something (a category) that has a page itself and repeating the header in the menu itself just so the header doesn't have to be a link isn't good design, either.
And just forgoing menus altogether is definitely not good design. If I have forty pages (eg. product lines) in six categories (eg. product types) most users don't want to see a list of forty-six links which they have to hunt through. If someone wants to know about my portable media players they don't want to wade through links to my premium sound systems. Overwhelming people with barely-structured options (and having all of them on the screen will look like bad structuring) is unlikely to keep them on the site.
Of course I could make people navigate to the category first and have them pick the product from there but this severely limits the speed at which they can explore the site. This can be enough to turn away people who don't know exactly where I put what they're looking for. If it takes someone ten page loads to find the product where it could take them one I'm clearly doing something wrong.
So what do we do? How do you implement a navigation that doesn't permanently keep all links on the screen yet doesn't require the user to load several different pages to get to their goal?
What I really hate about Idle is that if you use the Slashdot RSS feed it's impossible to distinguish between an Idle story and a regular one. You also can't filter out Idle. I'm thinking about writing a web scraper that obtains the regular RSS feed, logs into /., grabs my filtered story list and uses that to sanitize the RSS feed, which is then presented to me.
Alternatively, /. could just offer a second RSS feed for those who are perfectly aware of xkcd, waterskiing squirrels and the like without reading about them on /..