Buried in the published outcomes for this unit is a sentence most students read past. One outcome asks you to extend your knowledge, acquire new knowledge and connect it to conceptual frameworks in operating systems and networks "without explicit instruction". That is not a warning hidden in fine print. It is an assessed outcome, stated openly, and it means part of what the unit examines is something no lecture will hand you.
Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-08-25
Category: it-data
What the unit is, and why the entry rules are unusual
Direct answer: INFO1112 Computing 1B OS and Network Platforms is a 6-credit-point unit in the University of Sydney Faculty of Engineering, taught by Computer Science, offered in Semester 2 only, with no prerequisites and no prohibitions but a corequisite of ELEC1601 together with one of INFO1110, INFO1910, INFO1103 or INFO1113.
Evidence: The published unit page describes a unit introducing the principles and concepts of modern computer systems, covering operating system principles including mobile operating systems, computer networking principles including mobile networking, and writing applications that use OS and networking facilities while understanding the challenges common in distributed systems. Assumed knowledge is stated as a basic knowledge of Python, with the note that for most students INFO1110 should already have been passed in Semester 1.
Held together, the published record reads: code INFO1112, 6 credit points, University of Sydney, School of Computer Science, Semester 2 only, no prerequisite, no prohibition, corequisite ELEC1601 plus one programming unit, Python assumed, 13 published learning outcomes.
The corequisite is the structural fact worth pausing on, because it behaves differently from a prerequisite and students treat the two as the same thing. A prerequisite is knowledge you already hold. A corequisite is knowledge arriving in parallel, on another unit's schedule, which may not align with the week you need it. If a topic in INFO1112 feels like it assumes hardware understanding you do not yet have, the honest diagnosis is often that ELEC1601 has not reached it yet, and the fix is to read ahead rather than to conclude you are behind.
Why does "without explicit instruction" appear as an outcome?
Direct answer: Because the subject changes faster than a syllabus does, and the unit is assessing whether you can close a gap yourself. Three of the 13 outcomes are not about operating systems at all: managing time across a multi-week individual project, producing a clear written report, and acquiring knowledge without being taught it.
The self-direction and communication outcomes tend to be scanned and dismissed as boilerplate. They are the opposite. In a unit whose content is documentation-heavy and whose tools change between years, the ability to read a manual page, a protocol specification or a vendor document and extract what you need is the durable skill, and the outcome says so directly.
| Outcome group | Roughly what it covers | Count of the 13 |
|---|---|---|
| Self-direction and communication | project management, written report, learning without instruction | 3 |
| OS and network fundamentals | OS functions and subcomponents, networking layers | 2 |
| Tooling and hands-on breadth | system monitoring tools, experience across several operating systems | 2 |
| Server and mobile concepts | virtualisation, containers, handheld considerations | 1 |
| Security surfaces | interfaces where users and applications meet the OS and network, and where protection is needed | 1 |
| Internal mechanisms and algorithms | caching, process structures, memory mapping, layering, transport, multiplexing, packet switching, routing, scheduling | 2 |
| Building and distributed reality | writing code against OS and network facilities, failure and latency tolerance | 2 |
Evidence: Zimmerman (2002) described self-regulated learning as a cycle of setting a goal, choosing a strategy, monitoring whether it is working and adjusting, and argued that this capacity is teachable rather than innate. Bjork, Dunlosky and Kornell (2013) went further and showed that learners routinely misjudge their own progress, because the study methods that feel most effective, particularly rereading, are among the weakest at producing durable knowledge.
The Bjork finding about misjudged progress matters more here than in most units. Rereading lecture slides about packet switching produces a strong feeling of understanding and very little ability to diagnose a socket that will not connect. Doing the thing produces the reverse: less comfort, more capability.
Kapur (2008) found something closely related in a study of secondary-school problem solving: students who struggled unsupported with a problem before receiving any instruction on it later outperformed students who were guided from the first step, even though the unsupported group produced fewer complete solutions during the struggle itself. He called the pattern productive failure, and it describes almost exactly what an outcome that assesses learning "without explicit instruction" is designed to produce.
How should you handle a multi-week individual project?
Direct answer: By setting your own checkpoints, because the unit will not set them for you. One outcome names managing your time and activities across a multi-week individual project, which means the schedule is part of what is being assessed and not merely a condition of doing the work.
The failure pattern is uniform. A project released in week 4 and due in week 10 gets touched in week 4, ignored until week 8, then compressed into 2 evenings. The result is usually a working solution with a thin report, because the report is what gets cut when time runs out, and the report is a separate published outcome.
A schedule that fits this unit: read the whole specification in the week it appears and write down the parts you do not yet understand. Build the smallest thing that runs end to end early, even if it handles only one case. Then widen it. Keep a short log of what you tried and what happened, because that log becomes the report rather than being an extra task on top of it.
The single most useful habit is to separate the day you finish the code from the day you submit. Leave at least 2 days between them. Everything the outcomes ask for beyond correctness, including the write-up and the tidy-up, lives in that gap.
What does the report actually need to contain?
Direct answer: The reasoning behind your choices, not a narration of your code. A clear written report is its own outcome, and in a systems unit the interesting content is what you decided when the specification left room and what you observed when things failed.
Students write reports that restate what the program does, which the marker can read from the source. What cannot be read from the source is why you chose one buffer size, one protocol behaviour or one error-handling strategy over another, and what evidence you gathered before deciding.
Two of the most basic monitoring tools you will reach for here are older than Python itself. Mike Muuss wrote ping in 1983, built on the ICMP echo request specified in RFC 792 in 1981, and Van Jacobson wrote traceroute in 1987 to trace a packet's path through each router along the way. Both are still the first commands almost anyone diagnosing a network problem types, more than four decades later.
Three things belong in almost any report for this unit. First, the decisions you made and the alternative you rejected. Second, the measurements or observations you took, including the tools you used to take them, since one outcome covers using essential system tools to monitor OS and network status. Third, the limitations you know about, stated plainly. A limitation you name yourself reads as understanding. The same limitation found by a marker reads as an oversight.
Which concepts carry the most weight later?
Direct answer: Layering, and the tradeoffs that layering forces. One published outcome lists caching, process structures, memory mapping, layering, reliable and unreliable transport, multiplexing and packet switching in a single line, and among those layering is the idea that organises all the others.
Evidence: Saltzer, Reed and Clark (1984) set out the end-to-end argument, holding that functions such as reliability often cannot be implemented completely at a lower layer and are better placed at the endpoints, with lower layers providing them only as a performance optimisation. In their own words, “the function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system” (Saltzer, Reed, & Clark, 1984, p. 2). That single paper explains why reliable and unreliable transport both exist rather than one being simply better, which is exactly the kind of tradeoff a later exam question will ask you to reason about.
The pairing is not abstract. UDP, the unreliable transport the outcome refers to, was defined in RFC 768 in 1980. TCP, the reliable transport, followed in RFC 793 in 1981, the same year the Internet Protocol itself was set out in RFC 791. All three still run essentially unchanged decades later, which is itself a small piece of evidence for the end-to-end argument: the endpoints, not the middle of the network, carry the work of guaranteeing delivery.
Two more protocols are worth knowing by name and by number, since manual pages assume you already do. DNS, which resolves names to addresses, was set out in RFC 1035 in 1987. HTTP, the protocol most application-layer work in this unit ends up touching indirectly, reached its first standardised version, HTTP/1.0, in RFC 1945 in 1996. Neither name explains itself the way a mobile operating system's user interface does, which is exactly why the outcome asking you to read documentation without instruction exists.
A related outcome asks you to identify the interfaces where users and applications interact with the OS and the network, and where those need protection from unauthorised access. Saltzer and Schroeder (1975) laid out the design principles that still frame that discussion, including economy of mechanism, complete mediation and least privilege. Naming a principle when you identify a protection boundary turns a description into an argument.
The published description also names mobile networking specifically, and the protocol most responsible for making that work at scale is IPv6, standardised in 2017 as RFC 8200, replacing the address space that RFC 791 had set out for IPv4 back in 1981.
The seven layers behind this idea have an official source. ISO/IEC 7498-1, published in 1994, is the standard that formalises the OSI reference model most systems units still teach layer by layer. The Internet's own stack compresses the same idea into four layers, documented in 1989 in RFC 1122, which is why a diagram from a networking textbook and a diagram from a systems textbook can look like they disagree when they are describing the same stack at a different resolution. INFO1112's own outcomes mix vocabulary from both traditions, so knowing which model a term comes from is worth more than it looks. The physical and data link layers at the bottom of both models are where mobile networking actually lives, and the standard most relevant to a phone or laptop on campus Wi-Fi is IEEE 802.11, first published in 1997 and revised repeatedly since, most recently as 802.11be around 2024. Its wired sibling, Ethernet, comes from the same IEEE working group as IEEE 802.3, first published in 1983 and still the dominant wired standard in most computer labs.
The practical version: whenever you meet a mechanism in this unit, ask what it would cost to move that mechanism one layer up or one layer down. If you can answer, you understand it. If the question feels meaningless, you have memorised it.
What if your programming background is thin?
Direct answer: The assumed knowledge is basic Python, and the unit page notes that most students will have passed INFO1110 in Semester 1. If that is not your situation, the gap to close is usually file handling and error handling rather than algorithms.
The code you write here is not algorithmically hard. It opens and closes files, writes to disk and sends application-layer data to remote applications, which is what one outcome describes. What makes it feel hard is that the failures are external. A file that is not there, a port already in use, a connection that closes mid-transfer: none of these are bugs in your logic, and none of them appear when you test on your own machine under ideal conditions.
Build the habit of asking what the operating system will return when the request cannot be satisfied, and handle that path first. Students who write the success path and bolt on error handling at the end usually discover that the error path needed a different structure entirely.
For students working in English as an additional language, the specific difficulty in this unit is documentation rather than lectures. Manual pages and protocol documents are written in a compressed register with heavy noun phrases and few examples. Reading them slowly is not a weakness, and translating 1 page carefully is worth more than skimming 5.
Python itself has a long head start on this material. The language was first released in 1991, and the socket and file-handling primitives you call in this unit have changed remarkably little since, which is why decade-old manual pages and Stack Overflow answers usually still apply. The gap most self-taught students hit is not the language, it is the C-derived error codes the operating system returns underneath it, things like a connection refused or a permission denied, which Python surfaces as an exception but does not explain.
What kind of help is worth having on a self-directed unit?
A mentor writing any part of your project would remove the exact thing this unit assesses. On a unit built around self-direction, the useful work is upstream of the code: reading the specification together to surface what it leaves open, planning the checkpoints so the report is not the thing that gets cut, and afterwards reading your draft report for whether it explains decisions rather than describing behaviour.
If you are on the tutoring pathway, bring the specification and your current schedule rather than a broken program. The most expensive problems in this unit are usually sequencing problems, and they are visible weeks before they become code problems.
Frequently asked questions
When is INFO1112 offered?
Semester 2. The page lists Semester 2 offerings across multiple years at Camperdown/Darlington, so plan the rest of your semester around a unit that is not available at other times.
Do I need a prerequisite?
The page lists no prerequisites and no prohibitions. It does list corequisites of ELEC1601 together with one of INFO1110, INFO1910, INFO1103 or INFO1113, which means you take them alongside rather than before.
What programming do I need?
Basic Python is the stated assumed knowledge, and the page notes most students will have passed INFO1110 in Semester 1.
How much of it is hands-on?
Both, and the outcomes are explicit about it. Some ask you to understand principles, while others ask you to demonstrate experience with several operating systems and to use system tools, which cannot be satisfied by reading alone.
How much does the report matter?
Producing a clear written report is one of the published outcomes in its own right. Treat it as assessed work rather than as documentation added at the end.
Related reading
- INFO1110: introduction to programming
- INFO1113: object-oriented programming
- Tutoring from MAAS mentors
Ask a MAAS mentor about your unit
References
Bjork, R. A., Dunlosky, J., & Kornell, N. (2013). Self-regulated learning: Beliefs, techniques, and illusions. Annual Review of Psychology, 64, 417–444. https://doi.org/10.1146/annurev-psych-113011-143823
Kapur, M. (2008). Productive failure. Cognition and Instruction, 26(3), 379–424. https://doi.org/10.1080/07370000802212669
Saltzer, J. H., Reed, D. P., & Clark, D. D. (1984). End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4), 277–288. https://doi.org/10.1145/357401.357402
Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308. https://doi.org/10.1109/PROC.1975.9939
Zimmerman, B. J. (2002). Becoming a self-regulated learner: An overview. Theory Into Practice, 41(2), 64–70. https://doi.org/10.1207/s15430421tip4102_2