I go to a technical school with a large, well regarded, architecture department. Unlike the other engineering departments that make up the majority of the school, architecture has a slight female majority.
There are several interesting factors in terms of work there, actually. Architecture simultaneously have to do a great deal of group work, and have more emphasis placed on individual merit, then almost any other discipline.
Where it gets more interesting is that the professors, and the program, actively encourage architecture students to develop large, non-team player, egos, since this is apparently required in order to actually get your designs built.
After looking briefly at this, it is an entirely different beast. It is a full Cell processor, with 8 SPE's and a PPE and 5GB of RAM, as well as Flash memory that allows it to boot Cell Linux. It's really a system on a PCI-E board, rather then an accelerator board.
The immediate thing that comes to mind with this support, right after "awesome", is questions about streaming support. The user experience of progressive download is really terrible, especially over a slow net connection.
Those numbers are pretty abysmally bad, actually. # hdparm -tT/dev/sdc/dev/sdc:
Timing cached reads: 560 MB in 2.00 seconds = 279.65 MB/sec
Timing buffered disk reads: 188 MB in 3.00 seconds = 62.59 MB/sec
sdc is a 7.2k RPM SATA II drive with 16MB of cache. However, I'd take this with a grain of salt, given that the -t test uses sequential reads, which are optimal for hard drives, rather then a random access pattern that would advantage the SSD markedly.
TFA doesn't really reflect what the new API is meant to do. Having done some work on Facebook applications, one of the major issues that tends to come up is the storage of user data. Previously, you would need to store any information you needed in your own database. For significantly popular applications, this presents a major load issue. With the new API, it looks like developing applications with a high level of persistent information should be simpler, and require less load on the applications server.
I'd also strongly suspect that Facebook would crack down hard on anyone trying to use this API to store large quantities of data.
Clearly you don't know any architects, all the ones I know pirate software like crazy. After all, AutoCAD,3DSMax, Adobe Creative Suite, Dreamweaver, and so on are not cheap by any means...
It is really quite readable, we used it as a text for my Operating Systems class. Though I wouldn't recommend anyone who wasn't already fairly adept look at it too closely, since it doesn't line up with modern practice in many regards (the one that comes to mind is the inclusion of a binary that exec()s/etc/init as an array in main()).
It does work fairly well, except that its quite difficult to detect anything but the most blatant, full auto rifle type cheats. If someone comes up with something more subtle, it is really hard to pick out whether they're quite good or cheating. I know I err strongly on the side of not kicking people, and I'm fairly certain that it has made me not kick people who were cheating. Of course, I've also been on the other end of it, a few times I've been accused of cheating simply because I'm fairly good.
I agree that that might not have been the best usage on my part, I was thinking in terms of Silverlight as an alternative to
<canvas>, rather then in GUI API terms.
One of the interesting things with Moonlight is that its develops plan to implement a simple C# canvas object, which allows it to be used for for standalone application development, or to embed widgets into other programs, such as the Gnome desktop. So, even if Microsoft manages to destroy compatibility with Silverlight, the Moonlight code will still have a lot of potential in the Gnome environment, which currently lacks such tools.
Well, the Windows version has an openGL renderer, it is merely not the default. Also, the level of abstraction seems to be pretty high, since much of the user interface is defined by XML files, which are parsed using Expat. So, the port probably wasn't absurdly difficult.
Slashdot Mirror
I go to a technical school with a large, well regarded, architecture department. Unlike the other engineering departments that make up the majority of the school, architecture has a slight female majority. There are several interesting factors in terms of work there, actually. Architecture simultaneously have to do a great deal of group work, and have more emphasis placed on individual merit, then almost any other discipline. Where it gets more interesting is that the professors, and the program, actively encourage architecture students to develop large, non-team player, egos, since this is apparently required in order to actually get your designs built.
After looking briefly at this, it is an entirely different beast. It is a full Cell processor, with 8 SPE's and a PPE and 5GB of RAM, as well as Flash memory that allows it to boot Cell Linux. It's really a system on a PCI-E board, rather then an accelerator board.
The immediate thing that comes to mind with this support, right after "awesome", is questions about streaming support. The user experience of progressive download is really terrible, especially over a slow net connection.
Those numbers are pretty abysmally bad, actually. /dev/sdc /dev/sdc:
# hdparm -tT
Timing cached reads: 560 MB in 2.00 seconds = 279.65 MB/sec
Timing buffered disk reads: 188 MB in 3.00 seconds = 62.59 MB/sec
sdc is a 7.2k RPM SATA II drive with 16MB of cache.
However, I'd take this with a grain of salt, given that the -t test uses sequential reads, which are optimal for hard drives, rather then a random access pattern that would advantage the SSD markedly.
TFA doesn't really reflect what the new API is meant to do. Having done some work on Facebook applications, one of the major issues that tends to come up is the storage of user data. Previously, you would need to store any information you needed in your own database. For significantly popular applications, this presents a major load issue. With the new API, it looks like developing applications with a high level of persistent information should be simpler, and require less load on the applications server.
I'd also strongly suspect that Facebook would crack down hard on anyone trying to use this API to store large quantities of data.
Clearly you don't know any architects, all the ones I know pirate software like crazy. After all, AutoCAD,3DSMax, Adobe Creative Suite, Dreamweaver, and so on are not cheap by any means...
It is really quite readable, we used it as a text for my Operating Systems class. Though I wouldn't recommend anyone who wasn't already fairly adept look at it too closely, since it doesn't line up with modern practice in many regards (the one that comes to mind is the inclusion of a binary that exec()s /etc/init as an array in main()).
It does work fairly well, except that its quite difficult to detect anything but the most blatant, full auto rifle type cheats. If someone comes up with something more subtle, it is really hard to pick out whether they're quite good or cheating. I know I err strongly on the side of not kicking people, and I'm fairly certain that it has made me not kick people who were cheating. Of course, I've also been on the other end of it, a few times I've been accused of cheating simply because I'm fairly good.
I agree that that might not have been the best usage on my part, I was thinking in terms of Silverlight as an alternative to <canvas>, rather then in GUI API terms.
One of the interesting things with Moonlight is that its develops plan to implement a simple C# canvas object, which allows it to be used for for standalone application development, or to embed widgets into other programs, such as the Gnome desktop. So, even if Microsoft manages to destroy compatibility with Silverlight, the Moonlight code will still have a lot of potential in the Gnome environment, which currently lacks such tools.
Yes, the project has been working on support for non-x86 architectures. See http://www.reactos.org/wiki/index.php/PowerPC
Have a look at ptrace(2). You'd be supprised what you can do to another process you control.
Well, the Windows version has an openGL renderer, it is merely not the default. Also, the level of abstraction seems to be pretty high, since much of the user interface is defined by XML files, which are parsed using Expat. So, the port probably wasn't absurdly difficult.
And considering that Internet Explorer barely supports CSS2, it's going to be a while...
The magnets deteriorating and/or the coating breaking is a serious issue, see this article for an example.