SCO's argument is far more bizarre than that. They claim that since AIX and Dynix might have touched UNIX code once upon a time, all code ever written for AIX and Dynix since then must be covered by the contract terms of IBM's license for UNIX. Those terms talk about "methods and concepts" as protected entities. IBM used some of those allegedly protected methods and concepts when, say, they moved JFS over to OS/2, then implemented the Linux version of JFS using that as a reference. It's not about AIX. They're trying to argue that Linux inherited from OS/2 inherited from AIX touched UNIX, so (of course) they own the things in Linux.
Their theory of derived works is totally at right angles to reality. That isn't the way it works. However, Judge Wells is not permitted to smack them down. That falls to Judge Kimball (the trial judge) and, perhaps, a jury.
This is an annoying delay but really isn't going to change the outcome of the case.
Bright, vivid, and rich. A standard LCD panel looked positively gray and washed out next to this thing. Think about the blue you see on iridescent butterfly wings: this display can reproduce that colour.
This page gives a good overview of what the color gamut is and just how little of it a monitor can cover. By using six primaries instead of three, the Irodori team was able to cover almost the entire color volume.
This is the first projector I've ever seen that could do justice to something like a MaxfieldParrishpainting.
The projector itself can be replaced by several digital LCD projectors operated by a stagemaster system designed to keep the individual units in sync,
This brings into play one other serious problem: keeping the color and luminance profiles of the projectors in sync, including smoothing out the seams where projectorss overlap. It turns out that this is harder than you might expect. Also, the possibility of immersive teleconferencing on such a display is really cool, but requires unreal amounts of bandwidth (gigabit speeds, generally).
I think that a system like this will probably be deployed eventually, as the costs of digital projectors continue to drop, but at the moment there are still some serious problems to be solved.
At work the two machines I use regularly for interactive walkthroughs of large environments (10-100 million triangles) have 64MB and 128MB of texture memory, respectively. I am constantly running up against the 64MB limit and I'm fast approaching the 128MB one. Here's how it breaks down:
9 megabytes so far. No problem. Double that when I push the resolution up to 1600x1200 for demos, but we'll ignore that for the moment. Now, the model I'm using has 19MB of surface texture, so we're up to 28MB. The system I'm running on this poor hypothetical card uses 512x512 textures to replace distant geometry. Each one takes up 768K of memory and I've generally got a working set of between 40 and 60 textures. There's another 30-45MB, so total usage is somewhere between 58 and 73MB. Add in shadow maps and we lose another 20 or 30MB. The 64MB card is now swapping to AGP memory. The 128MB card is filling fast. It's adequate for the current generation of the system I'm running, but before I can write the next couple versions I'm going to have to implement some serious resident-texture-set cache management.
Now, you can certainly argue that this is an atypical application. You would be quite correct. However, I do need that much video memory and I do use it. Yes, it's massive overkill if you want to play Quake, Unreal, whatever, but once you start looking into more exotic applications it's easy to get into situations where you can use arbitrary amounts of texture RAM. Real-time shading can get you there in a hurry, too, once you start using textures as lookup tables for expensive-to-compute functions (e.g. light fields or factorized BRDFs) or caching the framebuffer for later re-use.
So yes, 90% of the programs 90% of users will run will currently fit neatly in 64MB of video memory, but there definitely exist systems that require more than that.
At a SIGGRAPH course on real-time shading last week, Eric Chan described a version of the Stanford compiler that broke a shader down into its component passes and used Cg as an intermediate language when aiming at NVIDIA cards. (Eric -- or anyone else who was at that course -- if you're reading this, I'd welcome corrections. I know it was the Stanford project and Cg as an intermediate language but I'm hazy on the details.)
Current hardware/drivers don't expose any way of [texture lookups in vertex shaders / position change in fragment shaders] so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use.
Exactly. This goes back to the Richards' claim that the Right Solution is to program everything in C/C++ and make the compiler smart enough to figure out how to partition it all into vertex shaders, fragment shaders, multiple passes, scene graph management, vector processing... I don't want a fully general language down in the fragment shaders. I want to know about what the hardware there can and can't do so I can make things run fast.
I think what Richards is overlooking in his commentary is that Cg is not *supposed* to be a general-purpose graphics programming language. Its design goal was precisely what he said later in the article -- to expose the capabilities of current (and presumably future) NVIDIA hardware without requiring programmers to write assembly code. Likewise, conditionals like if, case, and switch aren't in there right now because the profiles the compiler is aimed at -- DirectX and OpenGL extensions -- don't yet support them. I expect this to change.
Also, Cg programs run at the level of vertices and pixels. This is the wrong place to be thinking about a scene graph: that happens at a much higher level of abstraction. Dealing with scene graphs in a fragment shader is a little bit like making L1 cache aware of the memory-management policy of whatever OS happens to be running.
After reading the article a few times, I think it's meant more as a "here's why our product is better than theirs" release than an honest criticism of the design of Cg. If he was interested in the latter, there are a few obvious issues. I won't go into them all, but here are two I ran into last week at a Cg workshop:
Cg limits shaders to single-pass rendering. This is a design limitation: there are lots of interesting multipass effects, and it's not all that difficult to get the compiler to virtualize the shader to do multipass on its own. The Stanford Real-Time Shading Project people wrote a compiler that does precisely that: it uses Cg as an intermediate language. The advantage of that design decision is that you-the-programmer have fuller control over what's happening on the hardware, which is the entire point of the exercise.
Cg requires that you write separate vertex and fragment shaders. You can't do things like texture lookups inside a vertex shader; you can't change the position of your vertices inside a fragment shader. Again, this gives you control over the details of the pipeline at the cost of some added complexity. This can be changed by changing the semantics of the language.
One final note: Cg is not the be-all and end-all of real-time shading languages. Nor is DirectX 8.1, 9, or whatever. Nor is the SGI shading language. Real-time shading on commodity hardware is still a new enough field that the languages and the hardware are evolving. DirectX 9 and OpenGL 2.0 both incorporate shading languages that will by nature be less tightly coupled to one vendor's hardware. Watch those over the next year or so.
We already fixed this problem when CompuServe freaked out about GIFs. We all use PNG now for everything.
Here's the problem. PNG is a good solution when you want lossless compression, which is (not coincidentally) exactly what GIF did. This matters when you actually care about the numbers in the image, or when you've got certain kinds of content (sharp edges and smooth color gradients in particular). JPEG is appropriate when you have pictures that look more like the real world... lots of variation, certain frequency distributions, tons of detail. The reason it works so well is that it removes information that you-the-user can't see and then does lossless compression on the rest. That is something that PNG doesn't do.
IANAL, but offhand I see two good bets for defeating this patent claim. The first is that it expires in two years: it was granted in 1987. The other is prior art: the original JPEG group was formed in 1985 by combining CCITT and ISO working groups trying to do roughly the same thing. (Source: The History of ISO 10918. I wasn't there; I'd appreciate corrections.)
This patent seems to cover most of the components of JPEG and some of MPEG, and I just can't imagine that the JPEG committee hadn't come up with at least some of that by 1987.
That said, I do hack video and image encoders but I'm not a lawyer. I hope to see this claim shot down in flames. Quickly. I'm bothered by the idea that someone could out of the blue come and claim patent rights over my dissertation before I even finish it.
It might also provide a less-expensive way to make 3-D videos. Precursor to holographic movies?
It's a step along the way, but it's got one major drawback: it only captures a scene from one viewpoint. As soon as you move away from that viewpoint you're going to see holes in the scene where the camera didn't capture any information. To fix this, you must either (a) keep the viewpoint fixed at the camera's center of projection or (b) capture multiple views of the environment to fill in the missing bits.
Cameras like this have another potential benefit: better video compression. There's a section of the MPEG-4 standard that provides for segmenting your scene into objects so you could, say, encode the weatherman separately from the backdrop he's waving his hands at. If you shoot with a camera like this that can give you a rough silhouette of major objects in the scene, you could spend more of your time doing high-quality encoding of the people running around in the foreground and less of your time on the background that doesn't change for the length of the shot.
That said, I'm awfully skeptical about their claims of precision. As another poster has mentioned, there's a reason why laser range scanners cost so much: building an accurate rangefinder with lots of dynamic range is hard. As for object segmentation... I personally don't believe the image they provide as an example. Take a look at the depth map of the people at the conference table. In particular, look at the tabletop. It's nearly parallel to the camera axis, which means that its depth should be increasing fairly rapidly, which means you should see a gradient from light (near) to dark (far) in that part of the image -- but no, it's all one color.
I suppose you can explain that as treating everything between depths D1 and D2 as a single object, but that doesn't work all that well in practice. What's far more likely in my opinion is that that object mask is a hand-created example rather than the actual output of the device.
Oh, I'll bet you do a Fourier transform more than several times a day. JPEG image compression and MPEG video compression are both based on the discrete cosine transform, which is really a discrete Fourier transform in sheep's clothing.
Remember how terribly slow JPEG decompression used to be back in the days of yore? That's a large part of the reason.
Come on now, when is the last time you wrote a data structure to store the primitive types of your language in a way that hasn't been done before?
You mean a completely new, genius-from-Mars, noone-ever-thought-of-that data structure? I haven't yet. I assert, however, that you need to know about all kinds of data structures. When you're building a system that's going to search hundreds of thousands (or more) of pieces of data, the difference between an O(log n) search tree and an O(n) linked list is often substantial -- seconds versus minutes. If you're actually stuck with that linked list, then a thorough knowledge of data structures will lead you to something like skip lists, which will let you get back a lot of the fast searching.
Programming is not about inventing new data structures, but you do need to know what's there, how it works, and (just as important) what it doesn't do well.
When is the last time you thought it necessary to analyze (algorithmically) code that you are writing?
Last week. The occasion before that was two weeks ago. Much of the code I write is for ideas so crazy noone has tried them before. Thinking about the algorithmic complexity of what I'm doing will make the difference between a program that runs overnight and one that takes a month and a half. That's just my own playpen... it's considerably worse for things like large weather simulations. There, algorithmic analysis is the difference between runtime of days or weeks versus years, or not being able to run a simulation at all.
Both of these are really the same point. Most programming is not about inventing radically new algorithms or data structures, just as most woodworking is not about revolutionizing the design of hammers, drills, and saws. Algorithms and data structures are tools, each with their own sets of strengths and weaknesses, and part of being a skilled craftsman is knowing which tool to use when.
No speech or press by a person can ever be censored for any reason, ever. Period.
"Good reasons" or "bad reasons" or "good information" or "some information shouldnt be out there" isn't good enough.
This is incorrect on a few counts. First, your speech may not, in general, be censored by the government in its capacity as a sovereign (as opposed to as an employer or a proprietor of an establishment like a library). The First Amendment only applies to the US government, and by extension (via the 14th Amendment) to the state governments. Once you get that far, there are more exceptions -- a few categories of speech not protected at all, a few that receive only intermediate protection, and then the vast majority that are totally protected. The exceptions are as follows:
Obscene speech, which must be patently offensive under contemporary community standards, appeal to prurient interests, and lack serious redeeming value. Child pornography falls under this category. This decision is always a judgement call. Merely indecent speech is protected: unless and until it crosses over into obscenity, you're free to do as you will.
Speech that creates a clear and present danger to the public interest, whether it immediately endangers public safety (e.g. shouting "Fire!" in a crowded movie theater), incites immediate illegal action ("That lousy no-good so-and-so! Let's go burn his house down!"), poses a serious threat to the government (i.e. not just rhetoric), or threatens the President or his family. There is a fine line here: you are allowed to advocate a (potentially) illegal act, but not incite people to perform it.
Fighting words, namely denigrating speech likely to cause the average person to fight back or retaliate right then.
Speech that defames -- slander and libel go here.
False or deceptive advertising is not protected speech.
Basically the government has to show three things before it can censor speech:
The restriction serves a compelling government or public interest,
There is no less obtrusive means available, and
The restriction is not "unconstitutionally vague" -- your average Joe should be able to decide whether or not it applies in a given case.
With very few exceptions, the government cannot restrict any other kinds of speech based on its content.
(Thanks to Jeannie Walsh for the course slides I used for this. They're online at the web site for a Computers and Society course that I taught last summer.)
You're a researcher who wants to evaluate the efficacy of different compression algorithms-- compression vs. quality loss, etc
Hypothetical, perhaps a bit contrived, but you get the general idea.
This hypothetical situation has actually happened to me in a multimedia networking class. In the course of studying current video and audio formats, we spent a couple weeks on MPEG2. We needed practical examples to analyze what real-world encoders do on a range of real data. Those examples? A second of Blade Runner here, a second there, from several parts of the movie with interesting things happening on screen. DeCSS was used to obtain the data.
I believe this is unquestionably fair use: the material is being used in an educational setting, the quantity taken is very small relative to the size of the whole (two or three seconds out of a movie lasting 117 minutes), and there's no possible way it could harm the potential market for DVDs of Blade Runner. Moreover, this particular example requires the original digital data from the disk: you can't do analysis of MPEG compression (including things like coding efficiency and macroblock distribution) from a VHS tape!
An obvious counter to this is "you didn't have to use Blade Runner". No, but in order to analyze the performance of real-world encoders on real-world media, we need the output of those encoders (namely, the digital data from a DVD) by definition.
I don't think it should be a federal crime to show students how media compression techniques actually perform outside the classroom.
Work weeks are rarely less than 45 hours, and average somewhere north of 50. During the year, I'm a graduate student; during the summer I work in Santa Clara, CA. A 32.9 hour work week takes me to Wednesday at the end of the day, or sometimes Thursday morning.
Slashdot Mirror
SCO's argument is far more bizarre than that. They claim that since AIX and Dynix might have touched UNIX code once upon a time, all code ever written for AIX and Dynix since then must be covered by the contract terms of IBM's license for UNIX. Those terms talk about "methods and concepts" as protected entities. IBM used some of those allegedly protected methods and concepts when, say, they moved JFS over to OS/2, then implemented the Linux version of JFS using that as a reference. It's not about AIX. They're trying to argue that Linux inherited from OS/2 inherited from AIX touched UNIX, so (of course) they own the things in Linux.
Their theory of derived works is totally at right angles to reality. That isn't the way it works. However, Judge Wells is not permitted to smack them down. That falls to Judge Kimball (the trial judge) and, perhaps, a jury.
This is an annoying delay but really isn't going to change the outcome of the case.
So what do these new colours look like?
Bright, vivid, and rich. A standard LCD panel looked positively gray and washed out next to this thing. Think about the blue you see on iridescent butterfly wings: this display can reproduce that colour.
This page gives a good overview of what the color gamut is and just how little of it a monitor can cover. By using six primaries instead of three, the Irodori team was able to cover almost the entire color volume.
This is the first projector I've ever seen that could do justice to something like a Maxfield Parrish painting.
This brings into play one other serious problem: keeping the color and luminance profiles of the projectors in sync, including smoothing out the seams where projectorss overlap. It turns out that this is harder than you might expect. Also, the possibility of immersive teleconferencing on such a display is really cool, but requires unreal amounts of bandwidth (gigabit speeds, generally).
I think that a system like this will probably be deployed eventually, as the costs of digital projectors continue to drop, but at the moment there are still some serious problems to be solved.
Frame, depth, and stencil buffer: 1024x1024x(32 bits + 32 bits + 8 bits) = 9 megabytes
9 megabytes so far. No problem. Double that when I push the resolution up to 1600x1200 for demos, but we'll ignore that for the moment. Now, the model I'm using has 19MB of surface texture, so we're up to 28MB. The system I'm running on this poor hypothetical card uses 512x512 textures to replace distant geometry. Each one takes up 768K of memory and I've generally got a working set of between 40 and 60 textures. There's another 30-45MB, so total usage is somewhere between 58 and 73MB. Add in shadow maps and we lose another 20 or 30MB. The 64MB card is now swapping to AGP memory. The 128MB card is filling fast. It's adequate for the current generation of the system I'm running, but before I can write the next couple versions I'm going to have to implement some serious resident-texture-set cache management.
Now, you can certainly argue that this is an atypical application. You would be quite correct. However, I do need that much video memory and I do use it. Yes, it's massive overkill if you want to play Quake, Unreal, whatever, but once you start looking into more exotic applications it's easy to get into situations where you can use arbitrary amounts of texture RAM. Real-time shading can get you there in a hurry, too, once you start using textures as lookup tables for expensive-to-compute functions (e.g. light fields or factorized BRDFs) or caching the framebuffer for later re-use.
So yes, 90% of the programs 90% of users will run will currently fit neatly in 64MB of video memory, but there definitely exist systems that require more than that.
At a SIGGRAPH course on real-time shading last week, Eric Chan described a version of the Stanford compiler that broke a shader down into its component passes and used Cg as an intermediate language when aiming at NVIDIA cards. (Eric -- or anyone else who was at that course -- if you're reading this, I'd welcome corrections. I know it was the Stanford project and Cg as an intermediate language but I'm hazy on the details.)
Current hardware/drivers don't expose any way of [texture lookups in vertex shaders / position change in fragment shaders] so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use.
Exactly. This goes back to the Richards' claim that the Right Solution is to program everything in C/C++ and make the compiler smart enough to figure out how to partition it all into vertex shaders, fragment shaders, multiple passes, scene graph management, vector processing... I don't want a fully general language down in the fragment shaders. I want to know about what the hardware there can and can't do so I can make things run fast.
I think what Richards is overlooking in his commentary is that Cg is not *supposed* to be a general-purpose graphics programming language. Its design goal was precisely what he said later in the article -- to expose the capabilities of current (and presumably future) NVIDIA hardware without requiring programmers to write assembly code. Likewise, conditionals like if, case, and switch aren't in there right now because the profiles the compiler is aimed at -- DirectX and OpenGL extensions -- don't yet support them. I expect this to change.
Also, Cg programs run at the level of vertices and pixels. This is the wrong place to be thinking about a scene graph: that happens at a much higher level of abstraction. Dealing with scene graphs in a fragment shader is a little bit like making L1 cache aware of the memory-management policy of whatever OS happens to be running.
After reading the article a few times, I think it's meant more as a "here's why our product is better than theirs" release than an honest criticism of the design of Cg. If he was interested in the latter, there are a few obvious issues. I won't go into them all, but here are two I ran into last week at a Cg workshop:
One final note: Cg is not the be-all and end-all of real-time shading languages. Nor is DirectX 8.1, 9, or whatever. Nor is the SGI shading language. Real-time shading on commodity hardware is still a new enough field that the languages and the hardware are evolving. DirectX 9 and OpenGL 2.0 both incorporate shading languages that will by nature be less tightly coupled to one vendor's hardware. Watch those over the next year or so.
Here's the problem. PNG is a good solution when you want lossless compression, which is (not coincidentally) exactly what GIF did. This matters when you actually care about the numbers in the image, or when you've got certain kinds of content (sharp edges and smooth color gradients in particular). JPEG is appropriate when you have pictures that look more like the real world... lots of variation, certain frequency distributions, tons of detail. The reason it works so well is that it removes information that you-the-user can't see and then does lossless compression on the rest. That is something that PNG doesn't do.
IANAL, but offhand I see two good bets for defeating this patent claim. The first is that it expires in two years: it was granted in 1987. The other is prior art: the original JPEG group was formed in 1985 by combining CCITT and ISO working groups trying to do roughly the same thing. (Source: The History of ISO 10918. I wasn't there; I'd appreciate corrections.) This patent seems to cover most of the components of JPEG and some of MPEG, and I just can't imagine that the JPEG committee hadn't come up with at least some of that by 1987.
That said, I do hack video and image encoders but I'm not a lawyer. I hope to see this claim shot down in flames. Quickly. I'm bothered by the idea that someone could out of the blue come and claim patent rights over my dissertation before I even finish it.
It might also provide a less-expensive way to make 3-D videos. Precursor to holographic movies?
It's a step along the way, but it's got one major drawback: it only captures a scene from one viewpoint. As soon as you move away from that viewpoint you're going to see holes in the scene where the camera didn't capture any information. To fix this, you must either (a) keep the viewpoint fixed at the camera's center of projection or (b) capture multiple views of the environment to fill in the missing bits.
Cameras like this have another potential benefit: better video compression. There's a section of the MPEG-4 standard that provides for segmenting your scene into objects so you could, say, encode the weatherman separately from the backdrop he's waving his hands at. If you shoot with a camera like this that can give you a rough silhouette of major objects in the scene, you could spend more of your time doing high-quality encoding of the people running around in the foreground and less of your time on the background that doesn't change for the length of the shot.
That said, I'm awfully skeptical about their claims of precision. As another poster has mentioned, there's a reason why laser range scanners cost so much: building an accurate rangefinder with lots of dynamic range is hard. As for object segmentation... I personally don't believe the image they provide as an example. Take a look at the depth map of the people at the conference table. In particular, look at the tabletop. It's nearly parallel to the camera axis, which means that its depth should be increasing fairly rapidly, which means you should see a gradient from light (near) to dark (far) in that part of the image -- but no, it's all one color.
I suppose you can explain that as treating everything between depths D1 and D2 as a single object, but that doesn't work all that well in practice. What's far more likely in my opinion is that that object mask is a hand-created example rather than the actual output of the device.
Oh, I'll bet you do a Fourier transform more than several times a day. JPEG image compression and MPEG video compression are both based on the discrete cosine transform, which is really a discrete Fourier transform in sheep's clothing.
Remember how terribly slow JPEG decompression used to be back in the days of yore? That's a large part of the reason.
Come on now, when is the last time you wrote a data structure to store the primitive types of your language in a way that hasn't been done before?
You mean a completely new, genius-from-Mars, noone-ever-thought-of-that data structure? I haven't yet. I assert, however, that you need to know about all kinds of data structures. When you're building a system that's going to search hundreds of thousands (or more) of pieces of data, the difference between an O(log n) search tree and an O(n) linked list is often substantial -- seconds versus minutes. If you're actually stuck with that linked list, then a thorough knowledge of data structures will lead you to something like skip lists, which will let you get back a lot of the fast searching.
Programming is not about inventing new data structures, but you do need to know what's there, how it works, and (just as important) what it doesn't do well.
When is the last time you thought it necessary to analyze (algorithmically) code that you are writing?
Last week. The occasion before that was two weeks ago. Much of the code I write is for ideas so crazy noone has tried them before. Thinking about the algorithmic complexity of what I'm doing will make the difference between a program that runs overnight and one that takes a month and a half. That's just my own playpen... it's considerably worse for things like large weather simulations. There, algorithmic analysis is the difference between runtime of days or weeks versus years, or not being able to run a simulation at all.
Both of these are really the same point. Most programming is not about inventing radically new algorithms or data structures, just as most woodworking is not about revolutionizing the design of hammers, drills, and saws. Algorithms and data structures are tools, each with their own sets of strengths and weaknesses, and part of being a skilled craftsman is knowing which tool to use when.
"Good reasons" or "bad reasons" or "good information" or "some information shouldnt be out there" isn't good enough.
This is incorrect on a few counts. First, your speech may not, in general, be censored by the government in its capacity as a sovereign (as opposed to as an employer or a proprietor of an establishment like a library). The First Amendment only applies to the US government, and by extension (via the 14th Amendment) to the state governments. Once you get that far, there are more exceptions -- a few categories of speech not protected at all, a few that receive only intermediate protection, and then the vast majority that are totally protected. The exceptions are as follows:
Basically the government has to show three things before it can censor speech:
With very few exceptions, the government cannot restrict any other kinds of speech based on its content.
(Thanks to Jeannie Walsh for the course slides I used for this. They're online at the web site for a Computers and Society course that I taught last summer.)
You're a researcher who wants to evaluate the efficacy of different compression algorithms-- compression vs. quality loss, etc
Hypothetical, perhaps a bit contrived, but you get the general idea.
This hypothetical situation has actually happened to me in a multimedia networking class. In the course of studying current video and audio formats, we spent a couple weeks on MPEG2. We needed practical examples to analyze what real-world encoders do on a range of real data. Those examples? A second of Blade Runner here, a second there, from several parts of the movie with interesting things happening on screen. DeCSS was used to obtain the data.
I believe this is unquestionably fair use: the material is being used in an educational setting, the quantity taken is very small relative to the size of the whole (two or three seconds out of a movie lasting 117 minutes), and there's no possible way it could harm the potential market for DVDs of Blade Runner. Moreover, this particular example requires the original digital data from the disk: you can't do analysis of MPEG compression (including things like coding efficiency and macroblock distribution) from a VHS tape!
An obvious counter to this is "you didn't have to use Blade Runner". No, but in order to analyze the performance of real-world encoders on real-world media, we need the output of those encoders (namely, the digital data from a DVD) by definition.
I don't think it should be a federal crime to show students how media compression techniques actually perform outside the classroom.
Sigh. So much for Sony seeing the light.
Work weeks are rarely less than 45 hours, and average somewhere north of 50. During the year, I'm a graduate student; during the summer I work in Santa Clara, CA. A 32.9 hour work week takes me to Wednesday at the end of the day, or sometimes Thursday morning.