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…
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.
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.
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. 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.
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 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 one page carefully is worth more than skimming five.
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
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