Units
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/translations/freebsd-doc/articles_vm-design/en/units/?format=api&page=3
{ "count": 108, "next": null, "previous": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/units/?format=api&page=2", "results": [ { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "But in the <trademark class=\"registered\">UNIX</trademark> world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual <emphasis>physical</emphasis> pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in <emphasis>physical</emphasis> memory." ], "previous_source": "", "target": [ "But in the <trademark class=\"registered\">UNIX</trademark> world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual <emphasis>physical</emphasis> pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in <emphasis>physical</emphasis> memory." ], "id_hash": 7178675671754178708, "content_hash": 7178675671754178708, "location": "article.translate.xml:869", "context": "", "note": "(itstool) path: answer/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 105, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 74, "source_unit": "https://translate-dev.freebsd.org/api/units/102144/?format=api", "priority": 100, "id": 102144, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=e39fc77d3ca58094", "url": "https://translate-dev.freebsd.org/api/units/102144/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2019-10-20T12:20:04.225279Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned)." ], "previous_source": "", "target": [ "A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned)." ], "id_hash": -1376886729854784282, "content_hash": -1376886729854784282, "location": "article.translate.xml:878", "context": "", "note": "(itstool) path: answer/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 106, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/102145/?format=api", "priority": 100, "id": 102145, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=6ce450d0730e6ce6", "url": "https://translate-dev.freebsd.org/api/units/102145/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2019-10-20T12:20:04.232868Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "This is what Page coloring does. Instead of assigning <emphasis>random</emphasis> physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns <emphasis>reasonably-contiguous</emphasis> physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space." ], "previous_source": "", "target": [ "This is what Page coloring does. Instead of assigning <emphasis>random</emphasis> physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns <emphasis>reasonably-contiguous</emphasis> physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space." ], "id_hash": 4672035647183465942, "content_hash": 4672035647183465942, "location": "article.translate.xml:885", "context": "", "note": "(itstool) path: answer/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 107, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 71, "source_unit": "https://translate-dev.freebsd.org/api/units/102146/?format=api", "priority": 100, "id": 102146, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=c0d667aae8552dd6", "url": "https://translate-dev.freebsd.org/api/units/102146/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2019-10-20T12:20:04.242962Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "Note that I say <quote>reasonably</quote> contiguous rather than simply <quote>contiguous</quote>. From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does <emphasis>not</emphasis> have to assign truly contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation." ], "previous_source": "", "target": [ "Note that I say <quote>reasonably</quote> contiguous rather than simply <quote>contiguous</quote>. From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does <emphasis>not</emphasis> have to assign truly contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation." ], "id_hash": 5337985256232854066, "content_hash": 5337985256232854066, "location": "article.translate.xml:895", "context": "", "note": "(itstool) path: answer/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 108, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 114, "source_unit": "https://translate-dev.freebsd.org/api/units/102147/?format=api", "priority": 100, "id": 102147, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=ca14554f06082232", "url": "https://translate-dev.freebsd.org/api/units/102147/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2019-10-20T12:20:04.252864Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "Before moving along to the actual design let's spend a little time on the necessity of maintaining and modernizing any long-living codebase. In the programming world, algorithms tend to be more important than code and it is precisely due to BSD's academic roots that a great deal of attention was paid to algorithm design from the beginning. More attention paid to the design generally leads to a clean and flexible codebase that can be fairly easily modified, extended, or replaced over time. While BSD is considered an <quote>old</quote> operating system by some people, those of us who work on it tend to view it more as a <quote>mature</quote> codebase which has various components modified, extended, or replaced with modern code. It has evolved, and FreeBSD is at the bleeding edge no matter how old some of the code might be. This is an important distinction to make and one that is unfortunately lost to many people. The biggest error a programmer can make is to not learn from history, and this is precisely the error that many other modern operating systems have made. <trademark class=\"registered\">Windows NT</trademark> is the best example of this, and the consequences have been dire. Linux also makes this mistake to some degree—enough that we BSD folk can make small jokes about it every once in a while, anyway. Linux's problem is simply one of a lack of experience and history to compare ideas against, a problem that is easily and rapidly being addressed by the Linux community in the same way it has been addressed in the BSD community—by continuous code development. The <trademark class=\"registered\">Windows NT</trademark> folk, on the other hand, repeatedly make the same mistakes solved by <trademark class=\"registered\">UNIX</trademark> decades ago and then spend years fixing them. Over and over again. They have a severe case of <quote>not designed here</quote> and <quote>we are always right because our marketing department says so</quote>. I have little tolerance for anyone who cannot learn from history." ], "previous_source": "", "target": [ "Before moving along to the actual design let's spend a little time on the necessity of maintaining and modernizing any long-living codebase. In the programming world, algorithms tend to be more important than code and it is precisely due to BSD's academic roots that a great deal of attention was paid to algorithm design from the beginning. More attention paid to the design generally leads to a clean and flexible codebase that can be fairly easily modified, extended, or replaced over time. While BSD is considered an <quote>old</quote> operating system by some people, those of us who work on it tend to view it more as a <quote>mature</quote> codebase which has various components modified, extended, or replaced with modern code. It has evolved, and FreeBSD is at the bleeding edge no matter how old some of the code might be. This is an important distinction to make and one that is unfortunately lost to many people. The biggest error a programmer can make is to not learn from history, and this is precisely the error that many other modern operating systems have made. <trademark class=\"registered\">Windows NT</trademark> is the best example of this, and the consequences have been dire. Linux also makes this mistake to some degree—enough that we BSD folk can make small jokes about it every once in a while, anyway. Linux's problem is simply one of a lack of experience and history to compare ideas against, a problem that is easily and rapidly being addressed by the Linux community in the same way it has been addressed in the BSD community—by continuous code development. The <trademark class=\"registered\">Windows NT</trademark> folk, on the other hand, repeatedly make the same mistakes solved by <trademark class=\"registered\">UNIX</trademark> decades ago and then spend years fixing them. Over and over again. They have a severe case of <quote>not designed here</quote> and <quote>we are always right because our marketing department says so</quote>. I have little tolerance for anyone who cannot learn from history." ], "id_hash": 3076698109664586470, "content_hash": 3076698109664586470, "location": "article.translate.xml:70", "context": "", "note": "(itstool) path: sect1/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 14, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 327, "source_unit": "https://translate-dev.freebsd.org/api/units/157217/?format=api", "priority": 100, "id": 157217, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=aab2a0a133ac6ae6", "url": "https://translate-dev.freebsd.org/api/units/157217/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-04-18T18:14:53.711648Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "Any codebase that will survive and be maintainable for years must therefore be designed properly from the beginning even if it costs some performance. Twenty years ago people were still arguing that programming in assembly was better than programming in a high-level language because it produced code that was ten times as fast. Today, the fallibility of that argument is obvious — as are the parallels to algorithmic design and code generalization." ], "previous_source": "", "target": [ "Any codebase that will survive and be maintainable for years must therefore be designed properly from the beginning even if it costs some performance. Twenty years ago people were still arguing that programming in assembly was better than programming in a high-level language because it produced code that was ten times as fast. Today, the fallibility of that argument is obvious — as are the parallels to algorithmic design and code generalization." ], "id_hash": -3502117949162657057, "content_hash": -3502117949162657057, "location": "article.translate.xml:126", "context": "", "note": "(itstool) path: sect1/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 18, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 72, "source_unit": "https://translate-dev.freebsd.org/api/units/157219/?format=api", "priority": 100, "id": 157219, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=4f65fa47bea3eadf", "url": "https://translate-dev.freebsd.org/api/units/157219/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-04-18T18:14:53.745294Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "$FreeBSD$" ], "previous_source": "", "target": [ "$FreeBSD$" ], "id_hash": -6157127918850188850, "content_hash": -6157127918850188850, "location": "article.translate.xml:38, article.translate.xml:40", "context": "", "note": "(itstool) path: info/pubdate\n(itstool) path: info/releaseinfo", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 10, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 1, "source_unit": "https://translate-dev.freebsd.org/api/units/229220/?format=api", "priority": 100, "id": 229220, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=2a8d7cc7984b59ce", "url": "https://translate-dev.freebsd.org/api/units/229220/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-01-09T14:33:02.530396Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/en/?format=api", "source": [ "Why do we interleave our swap space instead of just tack swap areas onto the end and do something fancier? It is a whole lot easier to allocate linear swaths of an address space and have the result automatically be interleaved across multiple disks than it is to try to put that sophistication elsewhere." ], "previous_source": "", "target": [ "Why do we interleave our swap space instead of just tack swap areas onto the end and do something fancier? It is a whole lot easier to allocate linear swaths of an address space and have the result automatically be interleaved across multiple disks than it is to try to put that sophistication elsewhere." ], "id_hash": -5189863536442483307, "content_hash": -5189863536442483307, "location": "article.translate.xml:662", "context": "", "note": "(itstool) path: answer/para", "flags": "", "labels": [], "state": 100, "fuzzy": false, "translated": true, "approved": false, "position": 81, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/229221/?format=api", "priority": 100, "id": 229221, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/en/?checksum=37f9e69c5597dd95", "url": "https://translate-dev.freebsd.org/api/units/229221/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-01-09T14:33:02.659800Z" } ] }