I would be inclined to say that plain old caching is a pretty safe practice. Many ISPs already do it for general HTTP web page traffic, so extending that to include Bittorrent traffic seems like an easy move. Still, since when does the possibility that something is illegal stop a corporation from doing it to give them a competitive edge?
I'm guessing that it would be easier to detect a cacheable source if it comes from the same.torrent file, however I don't see why you couldn't check all.torrent files to see if the checksum matched.
Granted, not every file that is cached is going to be useful, but there are a few reasons might be useful.
1. It stands to reason that people in geographically close areas are more likely to want similar files. Two random people in Oregon are more likely to like the same band or type of music than people from two different countries. So if you have 100 people that want to bittorrent an album, the chances are fair that 2-10 of them could reside on the same network.
2. It's also difficult to tell exactly how many times a certain file is downloaded. I opened up thepiratebay.org and looked under recent files. I pulled up a file that listed 288 seeders and 65 leechers. Above that it listed that it had been downloaded 65 times. I'm just guessing that if you have 288 seeders, and only 65 total downloads, your numbers are waaaaaay off.
3. Many (possibly most) people close the torrent when they are done downloading. This, combined with the above, makes it difficult to tell who exactly has grabbed the torrent, and if they are on the same network as you.
4. Bittorrent traffic supposedly accounts for about 35% of all internet traffic. What do you suppose is the amount of bittorrent traffic on a network that is downloaded by at least two people? Let's say 15% (a rather conservative number IMO). That's means caching would save 5% of all traffic they have to get from other networks. That's good for peering agreements.
5. Uploading on a cable modem is bad. The transmissions are asynchronous and uploading 1MB takes several times the available transmission time on a cable as downloading 1MB. A couple of people uploading in a single node can create serious latency/bandwidth issues for everyone else connected to the node. Anything a person had downloaded via bittorrent could be cached, and proxied the opposite direction, removing the strain on the cable modem infrastructure.
6. You can build a 10TB array for less than $20K USD pretty easily (easily because it would be a non-critical system). A $20K investment is minuscule in the telecom world for what it might be able to do.
Bittorrent caching might not make an impact for an ISP, but that's a dangerous assumption. There are a lot of reasons it might make a huge impact for an ISP, and it is certainly something that they should be exploring.
Wouldn't it be simpler to use transparent bittorrent caching? The cable modem endpoint lines would still be saturated, but their other lines would be fine. They would save bandwidth, and increase the quality of service.
I was actually referring to the numbers for getting in a car and flying flying in a plane. People make statements about their safety, but I have never seen any numbers to back up those statements.
Still, I wonder just how many Slashdotters have gotten someone (or been gotten) pregnant from a torn condom.
You have a higher chance of dying every time you get into an automobile then you do having a condom break on you AND having the girl become pregnant as a result. It happens, but it's rare.
I keep hearing people say this, but I seriously doubt it. What are my chances of dying when I get into an automobile? I've gotten into an automobile at least tens of thousands of times without dying, and I expect to be in the hundreds of thousands of times before I do die, and not while being in an automobile.
I suspect there is a really bad way of looking at the statistics to make it work, kind of like the "flying is safer than driving" argument. Please, if you have any information or citations about this, please let us all know.
all other activities I list above are more likely to injure you indicates you have a different actual reason for avoiding sex and are just using STD's as a cover.
You really can't know that about him. I personally have several mild phobias, including a fear of STDs. It's close to my fear of catching diseases you can't cure. And Ebola... how I fear Ebola.
As part of this, I have a fear of Mono, the "kissing disease". By your reasoning I must have a fear of kissing, and am just using my fear of Mono to avoid it. You would be wrong.
Never attribute to self delusion what can be more easily explained by good old paranoia.
But if you cannot trust your central log host to have an accurate copy of the logs because you are receiving log data from anyone who chooses to pretend they are your PCI impacted server
Why not just have the logging server log into the servers to be logged, and continually monitor all of their logs for changes? Certificates would ensure that each computer is who they say they are, and you don't have to worry about streaming data if it is just being read. Also, you could put the logging server behind a NAT firewall, which is next to impossible to "hack" through (as it will only forward requested data).
If you look at the Wikipedia article, you will see that it has a copper cable length similar to that of HMDI. However the 1.1 spec adds in a provision to use optical fiber, which should go as long as you need to. I'm very curious what type of fiber adapters you could use on copper plugs to put a device far away.
This is not an idea I could imagine anyone wanting to grind into the ground like that. Seriously mate, come outside with the rest of us and enjoy your Sunday afternoon.:)
Oh come now, you're really missing the forest here. The XHTML specification includes input and output details, so if something is received incorrectly within the scope of those details, the it is not valid according to the specification. A file sitting on a server may be valid, but as soon as it is served up incorrectly, it is invalid. (Serving it up ROT13'd would also be considered invalid)
Internet Explorer doesn't even have to claim that it supports it (in content negotiation), but it should accept it when it is sent and make a best effort. Honestly, it supports XHMTL 1.1 about as well as it supports CSS 2.1. Are you really suggesting that they do something such as not support any of CSS 2.1 until they can support it all?
Support for text/html was specifically removed from XHTML 1.1, and using it with 1.0 was pretty b0rked anyway. It was included for the short time they expected for browsers to catch up, but they couldn't have expected that IE would have almost a decade of lag in support.
While the linked document doesn't specifically state that using XHTML at all is a bad idea, I think it is implied by the many statements as to the issues. I particularly like this quote from it:
The worst problem, and the main reason (I suspect) for most of the REALLY invalid XHTML pages out there, is that authors who have no clue about XHTML simply copy and pasted their DOCTYPE from another
document. So even if you write valid XHTML, by using XHTML, you are likely to encourage authors who do not know enough to write valid XHTML to claim to do so.
But that isn't a liquid layout, i.e. one in which all three columns can change size to fit their content, like the GP asked for. It's necessary to fix the size of at least one of the columns to make it function with the CSS that's implemented by common browsers.
No, it is perfectly doable in CSS 2.1 without anything complex. Create three DIVs right next to each other with the style "display:table-cell" and they will stick and form to each other just like table cells would. (Relevant lines from the spec.) You could specify their widths, or do whatever you want. Now, every current browser out there has supported this for some time with the exception of Internet Explorer, but the original parent didn't ask about support, but specs.
Really, if IE had started supporting this when everyone else had, columns wouldn't even be a discussion now. As it stands, because IE doesn't support it, it's a headache to everyone. Personally, I'm of the opinion that you do display:table-cell and then make a special case for IE to get it to display the same. It saves a lot of trouble trying to get complex styling to work the same in IE and everything else.
It is worth noting that there is a new "column" style specified in the CSS3 drafts. It is a different type of column, like columns from a newspaper. If you have a really long text, you can have it take up the same area, but split into X number of columns, or columns of Y width. It's useful, but not the same as the 2/3 column page designs on the web right now.
And I think the main problem that XHTML+CSS has had is Internet Explorer and its craptastic handling of CSS
Actually, I think the main problem XHTML+CSS has had is that Internet Explorer just doesn't support XHTML. For XHTML 1.1 to be valid, it has to be served with the application/xhtml+xml content-type. Because Internet Explorer doesn't recognize this content-type (even though it probably would have required 2 minutes of coding to add it) it will offer the user a download dialog when it is offered. And because you can't serve XHTML pages with the correct content-type to 90% of users, many experts insist that no one should be writing XHTML pages.
I just checked, and it looks like Texas is covered in the "Western" and the "Central" parts of the tour. If the air conditioning is decent then I may have to look at it.
How many Volts would you say would be optimal for a DC system in structures? If DC systems became standardized, so that even office buildings had DC outlets, what voltage and amperage would you want to be supplying to those outlets?
I remember reading about the move to a 42-Volt car electrical systems a few years back, but it looks like it's happening a lot slower than they were hoping. For some reason it's difficult to find information on this, and strangely even Wikipedia fails miserably in this. Apparently it is supposed to make for a much better starter, as well as powering all of the extra electronics going into cars.
I've never known anyone with any sort of home automation, so I'm curious to hear the experiences of someone that has done such extensive personal work in it.
Maybe, but I'm not so sure. What is worse, someone being murdered, or the rights of hundreds of millions of people being removed for the sake of one corporation's profits? (Granted, had he murdered hundreds of millions of people, that would be worse.)
A lot of people sacrificed everything they owned, including their lives to build a country full of good human rights. People that seek to remove those rights in the name of greed should have [fill in something bad] done to them. Jack Valenti was one of those people.
Ironically, an atom bomb in India would weigh less than most other places. If you look at a gravitational map of the world, you will see that the Southern tip of India actually has a lower gravitational pull than most other areas in land. Almost 5% less than the norm.
For space travel, this means that they can actually shoot off rockets for cheaper than other places because they need to use less fuel for a lighter load. I'd be curious to see what this translates to in real world cost savings.
I'm going to skip out on using my mod points for your post and add some more related stories.
I've known several people that have spent some time with Michael Dell, including my father who has had some group sit downs with him. Every one of them has commented on how connected (opposite of disconnected) he was to the business, both management and technical wise. He may not make a great sysadmin with his current knowledge, but he's no slouch either. If you think for a minute that he doesn't know what's going on, you've sorely underestimate him. (Also have stories about how funny/nice he is.)
On a related note, I've talked to Kevin Rollins (ousted Dell CEO) a couple of times. He doesn't have all of the technical background that Michael Dell has, but he's no idiot. Kevin is a real sharp guy, and super nice to boot.
This is a legitimate question, and there are two very good reasons for switching to Cairo (or rather, switching to another graphics framework).
1. The current rendering engine simply isn't flexible enough to handle some of the things they want to be able to do with it. For instance, finally properly supporting inline-block would be awesome. Full CSS2 support would be great, but on a bigger note, CSS3 will be solidified soon, and they are going to want to properly support it. Then there's other things like SVG.
2. Maintaining a cross platform rendering engine is a LOT of work. There are already several cross platform rendering engines that are much more advanced than what Gecko has been using, so why not switch to one of those and gain features while simultaneously freeing up programmers to work on other things? I don't know why Cairo in particular was chosen, but I imagine there were some good reasons.
Honestly, by the time FF3 is released, Windows 98 will be 10 years old. (Lets face it, no one should be using Windows Me.) The writer of the OS stopped supporting it years ago, and it was a security nightmare before they stopped. While it may be noble to want to support an OS that is likely being used by people in countries that don't have the financial ability to purchase more recent hardware, it isn't practical for many reasons. The OS itself can't support many newer things coming out, so not being supported by a newer version of a web browser isn't surprising. If these people want to run more recent software, they should upgrade their software to either an NT based kernel or switch to Linux. One is easy, and the other is free. Either way the expectations of developers are not that high.
Yes, those are both features that will be added. But I was referring to added CSS properties. For instance, display:inline-block has been glaringly absent for a very long time.
The full page zoom brings up an important point. Vista's new rendering system (and OSX's) use a vector based windows display system. They are trying to push people towards using a point based sizing from pixel based. That way no matter what the physical DPI of a monitor it, a window can be displayed the same size. Higher DPI monitors will just render things more clearly. This will get rid of the need to set monitors at a lower resolution because the text on applications is to tiny. Cairo will make it possible for Firefox to take advantage of that.
Cairo is not a speed demon, but it has been getting noticeably faster with ever release that they've made. It may be slower than what Firefox is currently using, but it's also a lot more useful. Their current Gecko rendering engine doesn't have the capability to do the things that they want to do, without a significant rewrite. So in this sense Cairo will add a ton of ability, fix a lot of memory leaks, and probably be at least as fast in a few releases. They will also gain time from all of the developers working on the current engine to have them work to improve some other part of Firefox.
The writer of Vorbis, Monty, has essentially been given the OK (by Red Hat, his current employer) to spend full time working on Vorbis 2.0, or "Ghost" as it is currently called (a from scratch audio codec). It is currently just a bunch of math and graphs, but he is working with Jean Marc, the writer of Speex, and they both have some really interesting ideas. Vorbis psycho models are still being developed by people in the community (but outside of Xiph). Currently Vorbis beats every other codec in the 128 kbps range, but they are hoping to get almost the same quality from 'Ghost' at less than 32kbps. If they can pull that off, it should put Xiph back on the map in a strong way.
MKV certainly has a specification, but it is not as clean as it should be. Why it appears to not define a lot of things is because they spec offers an extreme amount of flexibility. IE, you could have a valid MKV file that had no audio or video tracks, just attachments. Off the top of my head I can think of five different from scratch MKV parsers written by different people, so it is good enough for some people.
As far as being Windows centric, I honestly can't think of what you're talking about. I've never seen fonts attached to an MKV file, but it is certainly possible, and True Type Font files aren't Windows specific (unless Linux and Mac have recently been purchased by Microsoft). Being able to attach whatever files you want to an MKV is not specific to Windows or any other OS. I do know that one of the favorite uses for it is Anime, and a number of the fansubbers for anime use complex SSA subs (a text based subtitling format) for which there aren't any full implementations under Linux (last I looked). It will just display regular text. Is that Windows centric?
MP4 is an ISO standard with strong industry backing, and corporate A/V people almost never use anything that isn't an ISO standard with strong industry backing. There are all sorts of compatibility issues it resolves, but it also ends up being one of the slowest evolving tech groups out there. They use MP4 because in their eyes that is the only option. For people not in that industry, it's a fairly baffling way of thinking.
Slashdot Mirror
I would be inclined to say that plain old caching is a pretty safe practice. Many ISPs already do it for general HTTP web page traffic, so extending that to include Bittorrent traffic seems like an easy move. Still, since when does the possibility that something is illegal stop a corporation from doing it to give them a competitive edge?
I'm guessing that it would be easier to detect a cacheable source if it comes from the same .torrent file, however I don't see why you couldn't check all .torrent files to see if the checksum matched.
Granted, not every file that is cached is going to be useful, but there are a few reasons might be useful.
1. It stands to reason that people in geographically close areas are more likely to want similar files. Two random people in Oregon are more likely to like the same band or type of music than people from two different countries. So if you have 100 people that want to bittorrent an album, the chances are fair that 2-10 of them could reside on the same network.
2. It's also difficult to tell exactly how many times a certain file is downloaded. I opened up thepiratebay.org and looked under recent files. I pulled up a file that listed 288 seeders and 65 leechers. Above that it listed that it had been downloaded 65 times. I'm just guessing that if you have 288 seeders, and only 65 total downloads, your numbers are waaaaaay off.
3. Many (possibly most) people close the torrent when they are done downloading. This, combined with the above, makes it difficult to tell who exactly has grabbed the torrent, and if they are on the same network as you.
4. Bittorrent traffic supposedly accounts for about 35% of all internet traffic. What do you suppose is the amount of bittorrent traffic on a network that is downloaded by at least two people? Let's say 15% (a rather conservative number IMO). That's means caching would save 5% of all traffic they have to get from other networks. That's good for peering agreements.
5. Uploading on a cable modem is bad. The transmissions are asynchronous and uploading 1MB takes several times the available transmission time on a cable as downloading 1MB. A couple of people uploading in a single node can create serious latency/bandwidth issues for everyone else connected to the node. Anything a person had downloaded via bittorrent could be cached, and proxied the opposite direction, removing the strain on the cable modem infrastructure.
6. You can build a 10TB array for less than $20K USD pretty easily (easily because it would be a non-critical system). A $20K investment is minuscule in the telecom world for what it might be able to do.
Bittorrent caching might not make an impact for an ISP, but that's a dangerous assumption. There are a lot of reasons it might make a huge impact for an ISP, and it is certainly something that they should be exploring.
Wouldn't it be simpler to use transparent bittorrent caching? The cable modem endpoint lines would still be saturated, but their other lines would be fine. They would save bandwidth, and increase the quality of service.
I was actually referring to the numbers for getting in a car and flying flying in a plane. People make statements about their safety, but I have never seen any numbers to back up those statements.
Still, I wonder just how many Slashdotters have gotten someone (or been gotten) pregnant from a torn condom.
I keep hearing people say this, but I seriously doubt it. What are my chances of dying when I get into an automobile? I've gotten into an automobile at least tens of thousands of times without dying, and I expect to be in the hundreds of thousands of times before I do die, and not while being in an automobile.
I suspect there is a really bad way of looking at the statistics to make it work, kind of like the "flying is safer than driving" argument. Please, if you have any information or citations about this, please let us all know.
You really can't know that about him. I personally have several mild phobias, including a fear of STDs. It's close to my fear of catching diseases you can't cure. And Ebola... how I fear Ebola.
As part of this, I have a fear of Mono, the "kissing disease". By your reasoning I must have a fear of kissing, and am just using my fear of Mono to avoid it. You would be wrong.
Never attribute to self delusion what can be more easily explained by good old paranoia.
Why not just have the logging server log into the servers to be logged, and continually monitor all of their logs for changes? Certificates would ensure that each computer is who they say they are, and you don't have to worry about streaming data if it is just being read. Also, you could put the logging server behind a NAT firewall, which is next to impossible to "hack" through (as it will only forward requested data).
If you look at the Wikipedia article, you will see that it has a copper cable length similar to that of HMDI. However the 1.1 spec adds in a provision to use optical fiber, which should go as long as you need to. I'm very curious what type of fiber adapters you could use on copper plugs to put a device far away.
This is not an idea I could imagine anyone wanting to grind into the ground like that. Seriously mate, come outside with the rest of us and enjoy your Sunday afternoon. :)
Oh come now, you're really missing the forest here. The XHTML specification includes input and output details, so if something is received incorrectly within the scope of those details, the it is not valid according to the specification. A file sitting on a server may be valid, but as soon as it is served up incorrectly, it is invalid. (Serving it up ROT13'd would also be considered invalid)
Internet Explorer doesn't even have to claim that it supports it (in content negotiation), but it should accept it when it is sent and make a best effort. Honestly, it supports XHMTL 1.1 about as well as it supports CSS 2.1. Are you really suggesting that they do something such as not support any of CSS 2.1 until they can support it all?
Support for text/html was specifically removed from XHTML 1.1, and using it with 1.0 was pretty b0rked anyway. It was included for the short time they expected for browsers to catch up, but they couldn't have expected that IE would have almost a decade of lag in support.
While the linked document doesn't specifically state that using XHTML at all is a bad idea, I think it is implied by the many statements as to the issues. I particularly like this quote from it:
No, it is perfectly doable in CSS 2.1 without anything complex. Create three DIVs right next to each other with the style "display:table-cell" and they will stick and form to each other just like table cells would. (Relevant lines from the spec.) You could specify their widths, or do whatever you want. Now, every current browser out there has supported this for some time with the exception of Internet Explorer, but the original parent didn't ask about support, but specs.
Really, if IE had started supporting this when everyone else had, columns wouldn't even be a discussion now. As it stands, because IE doesn't support it, it's a headache to everyone. Personally, I'm of the opinion that you do display:table-cell and then make a special case for IE to get it to display the same. It saves a lot of trouble trying to get complex styling to work the same in IE and everything else.
It is worth noting that there is a new "column" style specified in the CSS3 drafts. It is a different type of column, like columns from a newspaper. If you have a really long text, you can have it take up the same area, but split into X number of columns, or columns of Y width. It's useful, but not the same as the 2/3 column page designs on the web right now.
Actually, I think the main problem XHTML+CSS has had is that Internet Explorer just doesn't support XHTML. For XHTML 1.1 to be valid, it has to be served with the application/xhtml+xml content-type. Because Internet Explorer doesn't recognize this content-type (even though it probably would have required 2 minutes of coding to add it) it will offer the user a download dialog when it is offered. And because you can't serve XHTML pages with the correct content-type to 90% of users, many experts insist that no one should be writing XHTML pages.
It's a mess.
I just checked, and it looks like Texas is covered in the "Western" and the "Central" parts of the tour. If the air conditioning is decent then I may have to look at it.
How many Volts would you say would be optimal for a DC system in structures? If DC systems became standardized, so that even office buildings had DC outlets, what voltage and amperage would you want to be supplying to those outlets?
I remember reading about the move to a 42-Volt car electrical systems a few years back, but it looks like it's happening a lot slower than they were hoping. For some reason it's difficult to find information on this, and strangely even Wikipedia fails miserably in this. Apparently it is supposed to make for a much better starter, as well as powering all of the extra electronics going into cars.
I've never known anyone with any sort of home automation, so I'm curious to hear the experiences of someone that has done such extensive personal work in it.
Do you have a webpage where you describe the things you've done in more detail?
Why have so many devices standardized on 12v if it is so wasteful?
Maybe, but I'm not so sure. What is worse, someone being murdered, or the rights of hundreds of millions of people being removed for the sake of one corporation's profits? (Granted, had he murdered hundreds of millions of people, that would be worse.)
A lot of people sacrificed everything they owned, including their lives to build a country full of good human rights. People that seek to remove those rights in the name of greed should have [fill in something bad] done to them. Jack Valenti was one of those people.
Ironically, an atom bomb in India would weigh less than most other places. If you look at a gravitational map of the world, you will see that the Southern tip of India actually has a lower gravitational pull than most other areas in land. Almost 5% less than the norm.
For space travel, this means that they can actually shoot off rockets for cheaper than other places because they need to use less fuel for a lighter load. I'd be curious to see what this translates to in real world cost savings.
I'm going to skip out on using my mod points for your post and add some more related stories.
I've known several people that have spent some time with Michael Dell, including my father who has had some group sit downs with him. Every one of them has commented on how connected (opposite of disconnected) he was to the business, both management and technical wise. He may not make a great sysadmin with his current knowledge, but he's no slouch either. If you think for a minute that he doesn't know what's going on, you've sorely underestimate him. (Also have stories about how funny/nice he is.)
On a related note, I've talked to Kevin Rollins (ousted Dell CEO) a couple of times. He doesn't have all of the technical background that Michael Dell has, but he's no idiot. Kevin is a real sharp guy, and super nice to boot.
This is a legitimate question, and there are two very good reasons for switching to Cairo (or rather, switching to another graphics framework).
1. The current rendering engine simply isn't flexible enough to handle some of the things they want to be able to do with it. For instance, finally properly supporting inline-block would be awesome. Full CSS2 support would be great, but on a bigger note, CSS3 will be solidified soon, and they are going to want to properly support it. Then there's other things like SVG.
2. Maintaining a cross platform rendering engine is a LOT of work. There are already several cross platform rendering engines that are much more advanced than what Gecko has been using, so why not switch to one of those and gain features while simultaneously freeing up programmers to work on other things? I don't know why Cairo in particular was chosen, but I imagine there were some good reasons.
Honestly, by the time FF3 is released, Windows 98 will be 10 years old. (Lets face it, no one should be using Windows Me.) The writer of the OS stopped supporting it years ago, and it was a security nightmare before they stopped. While it may be noble to want to support an OS that is likely being used by people in countries that don't have the financial ability to purchase more recent hardware, it isn't practical for many reasons. The OS itself can't support many newer things coming out, so not being supported by a newer version of a web browser isn't surprising. If these people want to run more recent software, they should upgrade their software to either an NT based kernel or switch to Linux. One is easy, and the other is free. Either way the expectations of developers are not that high.
Yes, those are both features that will be added. But I was referring to added CSS properties. For instance, display:inline-block has been glaringly absent for a very long time.
The full page zoom brings up an important point. Vista's new rendering system (and OSX's) use a vector based windows display system. They are trying to push people towards using a point based sizing from pixel based. That way no matter what the physical DPI of a monitor it, a window can be displayed the same size. Higher DPI monitors will just render things more clearly. This will get rid of the need to set monitors at a lower resolution because the text on applications is to tiny. Cairo will make it possible for Firefox to take advantage of that.
Cairo is not a speed demon, but it has been getting noticeably faster with ever release that they've made. It may be slower than what Firefox is currently using, but it's also a lot more useful. Their current Gecko rendering engine doesn't have the capability to do the things that they want to do, without a significant rewrite. So in this sense Cairo will add a ton of ability, fix a lot of memory leaks, and probably be at least as fast in a few releases. They will also gain time from all of the developers working on the current engine to have them work to improve some other part of Firefox.
The writer of Vorbis, Monty, has essentially been given the OK (by Red Hat, his current employer) to spend full time working on Vorbis 2.0, or "Ghost" as it is currently called (a from scratch audio codec). It is currently just a bunch of math and graphs, but he is working with Jean Marc, the writer of Speex, and they both have some really interesting ideas. Vorbis psycho models are still being developed by people in the community (but outside of Xiph). Currently Vorbis beats every other codec in the 128 kbps range, but they are hoping to get almost the same quality from 'Ghost' at less than 32kbps. If they can pull that off, it should put Xiph back on the map in a strong way.
MKV certainly has a specification, but it is not as clean as it should be. Why it appears to not define a lot of things is because they spec offers an extreme amount of flexibility. IE, you could have a valid MKV file that had no audio or video tracks, just attachments. Off the top of my head I can think of five different from scratch MKV parsers written by different people, so it is good enough for some people.
As far as being Windows centric, I honestly can't think of what you're talking about. I've never seen fonts attached to an MKV file, but it is certainly possible, and True Type Font files aren't Windows specific (unless Linux and Mac have recently been purchased by Microsoft). Being able to attach whatever files you want to an MKV is not specific to Windows or any other OS. I do know that one of the favorite uses for it is Anime, and a number of the fansubbers for anime use complex SSA subs (a text based subtitling format) for which there aren't any full implementations under Linux (last I looked). It will just display regular text. Is that Windows centric?
MP4 is an ISO standard with strong industry backing, and corporate A/V people almost never use anything that isn't an ISO standard with strong industry backing. There are all sorts of compatibility issues it resolves, but it also ends up being one of the slowest evolving tech groups out there. They use MP4 because in their eyes that is the only option. For people not in that industry, it's a fairly baffling way of thinking.