Foundations of Computer Science (uses ML as a teaching language)
Digital Electronics
Professional Practice and Ethics
"Computer Perspectives"
Discrete Mathematics
Probability
Programming in Java
Software Engineering
Operating Systems
Regular Languages and Finite Automata
Structured Hardware Design
(The above is half of the first year; the other half is spent doing mathematics and one Natural Sciences subject [Physics, Chemistry, Biology, Geology, Crystallography,...])
Second year:
ECAD
Concurrent Systems
Unix Tools
Logic and Proof
Digital Electronics
Data Structures and Algorithms
Computer Design
Numerical Analysis I
Further Java
Continuous Mathematics
Comparative Programming Languages
Operating System Functions
Compiler Construction
Computation Theory
Semantics of Programming Languages
Digital Communication I
Prolog for Artificial Intelligence
Introduction to Security
Computer Graphics and Image Processing
Foundations of Functional Programming
Databases
Complexity Theory
(Also a group project, usually in Java, Verilog, ARM assembler or a combination)
Third year:
Communicating Automata and Pi Calculus
Advanced Graphics
Information Theory and Coding
Types
Introduction to VLSI
Optimising Compilers
Digital Communication II
Information Retrieval
Neural Computing
Artificial Intelligence
Security
Natural Language Processing
Comparative Architectures
Specification and Verification
Numerical Analysis II
Computer Vision
Distributed Systems
Denotational Semantics
Business Studies
"Additional Topics"
(Also everyone does a major project for 25% of the year's marks.)
Ok, perhaps this sounds like an advert. I do believe it's a good course, though (after all, I did it...) and the variety really does help people to understand how everything fits together.
Speed is not really the issue with games on Linux. Operating system overheads are small enough not to matter. What does matter is the scheduling policy; "fair" schedulers like those used in Linux are not ideal; rate-based schedulers are much better for "multimedia" applications.
On Windows, games can tell the operating system to get out of the way and not interrupt them while they are running. On a single-user system this is fine. On Windows NT, games can do a similar thing and, mostly, this works. There's no reason why this can't be implemented on Linux; several projects have already done so.
Of course, the question then becomes "what happens when I want to run two or more of these applications at the same time"; a new design of operating system is required to support this.
Are there any CS degrees that do more than just learn:
How about the University of Cambridge (UK):
Ok, perhaps this sounds like an advert. I do believe it's a good course, though (after all, I did it...) and the variety really does help people to understand how everything fits together.
Speed is not really the issue with games on Linux. Operating system overheads are small enough not to matter. What does matter is the scheduling policy; "fair" schedulers like those used in Linux are not ideal; rate-based schedulers are much better for "multimedia" applications.
On Windows, games can tell the operating system to get out of the way and not interrupt them while they are running. On a single-user system this is fine. On Windows NT, games can do a similar thing and, mostly, this works. There's no reason why this can't be implemented on Linux; several projects have already done so.
Of course, the question then becomes "what happens when I want to run two or more of these applications at the same time"; a new design of operating system is required to support this.