A part of the settlement suggests the key to it lies in the two books. I have read the Da Vinci Code and no aspect of anything they did is reflected by this.
SPOILER WARNING My guess is it is scrambled somehow, like 'So Dark the con of man' and 'o, draconian devil' 'oh, lame saint', '13-3-2-21-1-1-8-5' but without knowing the other book I don't know what else to think about the code and how it would be related to this.
The other puzzles in Da Vinci Code I don't see as being applicable here..
The result is the same, downloadable music and movies will quickly be realized to potentially devastated in a common system's configuration, and either back up or just buying each disc will still be popular, either way optical media is here to stay.
a) only happens once before they realize the clickety sound of drive head skipping across disk platter is frequently unfixable (or not reasonably fixable)
b) Not a scalable strategy in terms of money. I.e. 4 dvd discs are under a buck if part of a spool, 20 GB of disk drive is still about 20-30 bucks (hard drives only get so cheap). But this was part of my point, DVD's are too small for high-def backups, and *if* people have strategies similar to the grandparent post in terms of download only video instead of purchasing media direct, whatever media is more available for cheap burnable configurations will have a particular advantage.
I am of the opinion that disc purchasing isn't going anywhere due to streaming, unlike other people who think streaming obsoletes everything. Blockbuster and Netflix can worry about streaming and IPTV, pay per view, but places like Suncoast, Best Buy, Wal Mart have little to worry about yet. MP3s are popular in general because they are relatively short and audio only, hence very small and manageable on a few GB of storage for extraordinarily large storage. A single DVD can hold most people's entire movie collection. Let's assume a movie collection would be 4 GB per movie and 1 movie per 3 album. 3 albums would be about 180 MB. If that rough guesstimate held, storage would have to be about 120 GB before I would think saveable streams should worry movie publishers.
It's probably will happen, but it's a ways off before 120GB storage flash parts, mini hard drives, or single disc optical media capable of that will be out.
1TB will be a single drive soon, anyway. I shall mock you when that single drive fails.
Seriously though, most people using computers know that drives fail and they risk losing everything on there, so they will want to back up purchases to relatively cheap media (optical media fits the bill). So you would still have an optical media competing for dominance, just in a slightly different way.
Mirroring and Striping with parity alleviate the issue of hard drive failure, but don't guard against software screw ups, bad software, or bad user mistakes.
Also, try playing your media library in your car for passengers. And don't say buy different media for home and car use, that would just be silly. If users didn't want their movies to be easily mobile and weren't adverse to putting their eggs in one basket by storing them on a disk array, they are probably happy with pay-per-view movies delivered over an infrastructured architected with this very purpose in mind.
This is the view of the lion's share of the market. I too usually just plop in a disc and rip to array, but I also like having the media available in case of storage subsystem failure of any sort.
BD-ROM drives logically have everything physically needed to do both formats. Ergo, BD players probably will feature cross-compatibility at some point (it already will have two lasers for legacy discs anyway). Maybe they'll have a unified laser device that changes the requirement for two lasers for new and legacy support.
HD-DVD only drives will be significantly easier to produce, using the same wavelengths as today. HD-DVD drives therefore can probably go lower in price.
So you'll end up with a market of HD-DVD only players, and players that will blay both HD-DVD and BD-ROM.
So studios logically pick HD-DVD because everyone can play it. Just ask OS/2 how supporting the competing standard as well as your own works when your competition does not return the favor..
The PS2 can play DVDs but precious few people use that feature that I know. PS2 using DVDs really doesn't affect the rest of the world except to mean that PS2 games will be DVD... True that DVD has no competition and was established well before PS2 came along, but it illustrates the point that people aren't too big on unified devices.
PSP is out and for a short while there was a fair amout of success around UMD movies. Novelty wore off quick and again, no one cares and the significance of UMD is not that movie studios care to support UMD, but PSP games are done on UMD. This is without an affordable similar alternative (video iPod is the only other thing reasonably in the market, and even then it isn't quite the same).
PS3 will use BD-ROM. That means games for PS3 will be Blue Ray. Depending on the cost and library available for Blue Ray and HD-DVD at the time of PS3 launch, the feature will probably be a moot point. If there is even a modest library of titles for HD-DVD and a player could be had for ~100 bucks, the BlueRay aspect of PS3 will be a moot point one way or the other. It *could* have an impact if all HD-DVD players and Blue Ray players on market are still around 500 dollars or more, or if the library of both were negligible. In essence, entering a market without reasonable competition before any market penetration has occured, since PS3 would be cheaper than buying a console *and* a movie player. If a separate player is under $100 bucks few will care about the movie playing feature of PS3.
I've only gotten my HD mythtv setup to 'crazy', acheiving 'mad crazy' is a huge step in the right direction.
Seriously though, not that hard. I have a box that does ATSC and mythtv and displays via DVI to HDMI cable to my TV. (AirStar HD5000 tuner, onboard GeFore 6150 for DVI video). It could do unencrypted QAM channels if I wasn't too much a cheapskate to buy cable.
I would be impressed if they had something that took CableCard or something for encrypted QAM channels on cable.
30 Watts could be clunkily done via a direct attach cable from PSU. Cooling probably is a fair issue, most accelerators in the market today don't have that much heat to dissipate, therefore meeting PCI-spec like requirements with a cooler is an issue for 1U systems that don't allow multi-width cards at all. Conjecture had been that the DIMM sockets were not being utilized, and that was my chief concern about a device sitting in that spot and crippling the memory capacity. HTX slot is fairly standardized and becoming more prevalent in the market, so building a single board isn't that much of a challenge, though some 940 platforms admittedly do not have that slot.
The other issue is how does it deal with other devices that may be connected via hypertransport to the socket it occupies? For example one strategy I see pursued to get more inter-node IO is to have, for example, a four socket opteron where each socket has two links to two processors and the third brought out for inter-node IO via PCI-E chips or HTX.
It could be interesting compared to clearspeed offerings, but the platforms I work with have moved on to AM2 for the future...
Might as well make it an HTX card rather than suck up a CPU socket that could otherwise be driving more memory (picture implies no attached memory). Most upcoming 940 platforms have HTX slots now for the equivalent performance/latency with a left over hypertransport links.
Just to make clear what is required... We can have it to 15 GB/s for most conversation (because he implied concurrent read/write, and most people just discuss unidirectional bandwidth) That brings us down to about 150-170 Gb/s required to measure a cross-sectional bandwith of 30 GB/s.
So, say, a 256 node cluster running something like GPFS or Lustre even on gigabit ethernet might play in the realm of 30 GB/s concurrent read-write throughput. This is assuming nodes contributing their storage to a pool and not having any SAN-like sharing which would mean a bottleneck there.
256 node clusters, while not common, would not surprise me to be under the administration of a handful of slashdot readers.
One, the price of all this stuff is exhorbitant, and most home applications could barely benefit from going from 100 MBit to Gigabit. Realistically, getting 1.5 microsecond latency and the ability to transfer GigaBYTES per second has no home use right now. Really exorbitant High definition streams top out at about 20 MBit/second for 1920x1080 MPEG-2, and of course no game demands that much throughput. Hard drives for home use can only theoreticly dump out 300 MB/s or so anyway (SATA II), and realistically except for cache operations you almost never acheive it.
Going to gigabit ethernet makes diskless systems close to theoretically working as fast as UDMA 66 drives, which allows for fun home projects working more smoothly. Latency for network operations is already similar to drive seek times, so going to insane latency won't help too much either.
Systems that benefit from this have to have large (many-drive) storage architectures to pull throughput from and large numbers of systems to have enough computational data to make the interconnect fabrics worth while. Before you begin to ever approach a system that large, your power/cooling bill would be insane.
If you were into the intrensic interesting stuff of this, you can learn most principles involved with good old ethernet, and fill the gaps with google research. It is undeniable that you learn more hands on, but if you ever really need to use it with a company or something and you have your bases covered, chances are you'd exceed most other candidates who aren't even aware of the technology.
For those not aware of how ethernet is limited latency wise regardless of what is done, I will explain a tad.
Ethernet is well architected for large deployments (enterprise-wide) with the packet routing (not IP routing) done on the switches. Menaing a computer sending a packet asks its switch to get it to 0A:0B:0C:01:02:03, having no idea where it will go. Switch only knows it's immediate neighbors, and will check/populate it's arp table to figure out the next entity to hand off. This means switches have to be really powerful because they are responsible for a lot of heavy lifting for all the relatively dumb nodes. This is not TCP, it is not IP, it is raw reality of ethernet networking. Aside from Spanning tree (which is not maintained for any other reason than keeping a network from getting screwed over by incorrect connections, not for performance), no single entity in the network has a map of how things look beyond its immediate neighbors.
IB, Myrinet, etc, are source routed. Every node has a full network map of every switch and system in the fabric. The task of computing communication pathways is distributed rather than concentrated (fits well with the whole point of clusters). node1 doesn't blindly say to the switch, 'send this to node636', it says to switch 'send this to port 5, and the next switch, put it out port 2, and the next switch, do port 9 and then it should be where it needs to be'.
There are more complicated issues their, but a lion's share of the inherent strength of non-ethernet interconnects is this.
Lately, the big contenders are: -Ethernet -Inifiniband -Myrinet
I haven't heard much about SCI or Quadrics lately, and just these three have been tossed around a lot lately. Points on each: -Ethernet is cheap, and frequently adequate. Low throughput and high latency, but it's ok. 10GbE ethernet is starting to proliferate to eliminate the throughput shortcomings, and RDMA is starting to possibly help latency for particular applications. Note that though overwhelmingly clusters put together using ethernet use IP stack to communicate over it, it is not exclusively true. There are MPI implementations available that sit right under the ethernet header layer. It bypasses the OS IP stack which can be very slow and reduces overhead per message. Increasing MTU also helps throughput efficiency. But for now only 1 Gigabit ethernet is remotely affordable at any scale (primarily due to current 10GbE switch densities/prices, adapters are no more expensive than Myrinet/Infiniband).
-Myrinet. With their PCI-E cards they achieve about 2 GBytes/sec bidirectional throughput, very nearly demonstrating full saturation of their 10GBit fabric. They also are among the lowest latency sitting right about 2.5 microsecond node-to-node latency as a PingPong minimum. Currently the highest single-link throughput technology realistically available to a customer (Infiniband SDR doesn't quite acheive it, about 200 or so MByte/s short, but DDR will overtake it as it realistically is available). Very focused on HPC and until recently also the only popular high-speed cluster interconnect that was very mature, easy to set up and maintain, and efficient. Now they are starting to embrace more interoperability with 10GbE, probably in response to the rise of infiniband.
-Infiniband. Until very recently immature (huge memory consumption for large MPI jobs, software stack that is highly complex and not easily maintanable, and the prominent vendor of chips (Mellanox), didn't acheive good latency. With Mellanox chips you are lucky to get into the 4 microsecond range or so. With Pathscale's alternative implementation (particularly on HTX), the lowest latency interconnect becomes possible (I have done runs with 1.5 microsecond end-to-end latency even with a switch involved). The maximum throughput is on the order of 1.7-1.8 GByte/s and more importantly is one of the faster technologies in ramping up to that. No technology acheives their peak throughput until about 4 MB message sizes, and Pathscale IB is remarkably a good performer down to 16k-32k message sizes. Additionally, IB has a broader focus and some interesting efforts. They make efforts to not only be a good HPC interconnect, but also to be a good SAN architecture that in many ways significantly outshines fibre channel. The OpenIB efforts are interesting as well. The huge downside is that for whatever reason no Infiniband provider has been able to demonstrate good IP performance over their technology. This particularly is an issue because most all methods of storage sharing from hosts are IP based. SRP is ok for the little amount of flexibility that strategy gives to be Fibre-Channel like, but nfs, smb, and image access like NBD and iSCSI all perform very poorly on Infiniband compared to Myrinet. iSER promises to alleviate that, but for the moment you are restricted to performance on the order of 2.4 gigabit/s for IP transactions. Myrinet has been able to deliver 6-7 Gigabit/s for the same measurements. You could overcome this by sharing storage enclosures and use something like lustre, GFS, or GPFS to communicate more directly with the storage over SRP, but generally speaking some applications demand flexibility not acheivable without IP performance.
And at the end of the day, I come home and run my home network on 100MBit ethernet, sigh. It is enough to run a diskless MythFrontend for HD content at least.
I think it's easy to say Star Control 2 was the definiitive game for the continued fame of Star Control. I'll also say that the PC version is the one people really got, and the 3DO's only legacy is being the one that they still had source code to make UQM a reality.
With this in mind, I would say their target market would be largely comprised of those who were around and immensely enjoyed Star Control 2. While probably many of that market have game consoles of some variety, they all are probably more likely to be heavily into their computer. People who played DOS games in the 90s generally were consistantly computer oriented, probably because it was more of a hastle back then for so many games that required x amount of conventional memory and you had to fiddle with things to get rid of memory resident things not needed for that game and move whatever else you could to 'high memory'. Those were the days...
Anyway, considering the bulk of their target market would be those who already played SC2, the platform that makes sense is personal computers. To go a step further, it should be cross-platform and run on at least Linux/x86 and Windows. Though I don't have definitive evidence for it, I strongly suspect large portions of SC2's fanbase is on linux and that uqm usage statistics may be enlightening. Additionally, developed correctly it isn't that hard to make even a fairly sophisticated game run on different Operating systems, so the cost/benefit ratio should be good regardless.
It's hard looking at their list of games to establish them to now be console-only, they haven't developed enough games, and none of them have been notable enough compared to SC2. Their best bet if they had the opportunity to do a sequel would be to target their old fans as closely as possible. If it is a good game, it would be a nice revival for their name which hasn't seen a big title since 1992.
AMD also has SSE2 for most recent cores and SSE3 for Venice and up. AMD embraces every extension intel produces, it is intel that has no interest in some AMD extensions (3dnow). However, Intel did certainly embrace AMD64 (of course not calling it that...) At least I haven't heard of intel system doing that.
My intel system flags (Pentium M): fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
My most recent AMD system (pre-venice): fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt 3dnowext 3dnow
It is of course true that whichever vendor has an extension released there is a short time in which it is exclusive to their product line, but it doesn't last long. I think AMD and intel have a long standing cross-licensing agreement that precludes either from locking out the other from new instructions/instruction sets.
1) If you are considering the virus' validity all by itself, it doesn't matter what language it is in. If you are considering it as a proof of concept for a new type of virus, the detail of it being written in assembly is a) not as damming as you portray and b) probably not indicative of a requirement going forward.
2) This is what *really* made me have to reply. You must have *no* idea of what exactly is ELF on a linux box. Every compiled application in the last 10 years or so has been almost exclusively ELF. Without ELF support, you simply don't have a working modern distribution. You could theoretically try to run the old a.out format, but that really isn't any more safe in the long term and highly impractical.
3) Again, the important aspect is 'proof-of-concept' This particular virus doesn't bother to attempt chdir.but that does not preclude the concept of more general implementation. But the rest of what you say is applicable. Once I would have said an inexperienced user frequently only bothers to run as root, since it makes things easier, but with the proliferation of strategies like Ubuntu, things are handled a lot more sanely. The lesson they learned is not to ask a typical user for a root password at *all*, lest they be tempted to use it for everything.
It is conceptually hard to see this thing spreading. The stategy of spawning from ELF applications means it has to be set executable by something prior to being run. In Windows they historically accomplish the analagous function by leveraging the weak strategy of filename based executable status and the 'friendly' feature of hiding extensions that only sometimes work, and you have 'nicepicture.jpg.pif' or something similar that a Windows app lazily hands the file over and then Windows make the lazy choice of honoring.exe. Now there are a lot of precautions to prevent this in an up to date Windows system, but architecturally this is how it happens. In linux, the permissions dictate and the permissions are not transferred with the file content (unless encapsulated by something like tar). gnome-open a potentially executable file without the executable permission and nothing interesting should happen.
Again, as non-root usage for even the lazy users increase, this strategy with respect to propogation becomes irrelevant as few users run applications capable of relaying the content that they would also have write access to. Now if by some miracle infected by a virus of this type with goals other than spreading, it can be almost as functionally devastating, despite the privilige separation. For the same reasons that the system files and other users are protected from a particular users activity, most of a single-user machine's important data is owned by the user. Sure, if attacked they could make a new user unaffected without reinstall as worst case, but they may have lost all their documents, records, and images they actually care about that aren't recoverable.
The net of it is that the stuff important to a desktop user is not protected from viruses, but the traditional executable binary approach of viruses just doesn't apply to linux. Exploiting buffer mismanagement and such in media players, document readers, image renderers, etc *are* applicable in linux as well as Windows and this would be the only sort of virus that I would watch to be a remote success. This strategy doesn't try to dance around the strong impedements at the low level architecture, but exploits the much more likely poorly coded app given permission to run legitimately by the low level platform.
Well, one, many applications can work in a very heterogeneous environment, if the work is divided correctly. The easiest examples are protein folding where each system can work an individual protein, and the faster ones don't need to wait to get more work units, rendering, breaking encryption, certain types of physics simulations.
Now let's assume you have an application where you can't efficiently divide the work such that there is no intrinsic codependency between node work, and that what you say holds, that the slowest node dictates performance for the whole cluster. The simple workaround is to have the number of jobs running on nodes be asymmetric. I.e. you have 6 systems at 1 GFlop/s each and 6 at 2 GFlop/s each. So on the first 6, run 1 'thread' per node, on the latter 6, run 2 threads per node. It would of course be more complex depending on the characteristics of the node and job, but generally if an application can be scaled to arbitrary number of nodes for computing, you can scale it asymmetrically. Of course, be sure the other subsystems of each node are sufficiently good to handle twice the workload, particularly memory.
Would massive surface mirrors be a more feasible solution? Many floating mirrors in the oceans, on roofs of buildings/houses/etc. That Time magazine scare piece on global warming had me wondering about that as one of the things mentioned was that a massive diminishing ice surface is a feedback loop. As it gets warmer, ice melts to water and as the surface area of the ice decreases in favor of non-reflecting water, the Earth absorbs rather than reflects more. If scientists stating decreasing ice surface area has an affect are correct, it stands to reason that adding more surface that is even more reflective would have the opposite effect. Sure it is within the atmosphere and therefore would mean the atmosphere sucks up more than the extra-planetary sort of solution, but it would be much more in reach without affecting solar output for everyone across the world (and by extension reducing the prospect of solar energy where applicable).
I would think a mirror surface that is completely reflective would be most effective, but light colored surfaces would have some effect as well.
The Top500 benchmark is double precision floating point operations, 64 bit. The platforms boasting seemingly unbelievable teraflop figures are flaunting single-precision (32-bit) performance. Though still boasting Rpeak when only Rmax really counts (theoretical maximum versus acheivable performance), it isn't an outright lie, just not taken in the same context as Top500.
Wherever I go, I've found in decent sized organizations the ones that look the least presentable but have managed to stick around a few years are among the best. Not because of anything intrinsic about the unkept look, it is because those are the ones that are good enough that the uptight suits couldn't justify firing in a million years *despite* the look that really rubs them the wrong way. If you don't dress very well and aren't bulletproof with respect to your technical merits, uptight suits up higher will find a reason to replace you with a more visually acceptable candidate, even if technically they aren't quite as good.
That just reflects people looking for info about a platform, has nothing to do with people running the distros, just what is popular to read about and think about and, to some extent, a popular choice for newcomers, not for those established with a distro already.
An analogy would be to look at how many people search for, say, a Ferrari versus how often people search for a Ford Focus. The Ferrari are more interesting and people search for them, but doesn't mean that the proportion of Ferrari drivers to Focus drivers is anywhere near what google search statistics would suggest with this methodology.
Having 20-30 booths worth of papor ballots counted by one electronic scanning machine is cheaper than 20-30 computers with touchscreens, period. Having the paper trail to attempt to audit is important for political reasons if not technical reasons. It's much harder to tamper with paper ballots than paper ballots at scale. True, their is nothing technically difficult about modifying a single ballot paper wise, but modifying thousands of ballots *and* coordinating such an effort with electronic vote counting machine tampering is far more difficult than tampering with any purely electronic database of votes. Would be fraud would have to be more sophisticated than if just having paper or electronic voting.
Manual paper ballot counting almost never occurs, so it isn't fair to put that counting time into the equation across the board.
Slashdot Mirror
A part of the settlement suggests the key to it lies in the two books. I have read the Da Vinci Code and no aspect of anything they did is reflected by this.
SPOILER WARNING
My guess is it is scrambled somehow, like 'So Dark the con of man' and 'o, draconian devil' 'oh, lame saint', '13-3-2-21-1-1-8-5'
but without knowing the other book I don't know what else to think about the code and how it would be related to this.
The other puzzles in Da Vinci Code I don't see as being applicable here..
Silly pre-30,000 userid geezers
The result is the same, downloadable music and movies will quickly be realized to potentially devastated in a common system's configuration, and either back up or just buying each disc will still be popular, either way optical media is here to stay.
a) only happens once before they realize the clickety sound of drive head skipping across disk platter is frequently unfixable (or not reasonably fixable)
b) Not a scalable strategy in terms of money. I.e. 4 dvd discs are under a buck if part of a spool, 20 GB of disk drive is still about 20-30 bucks (hard drives only get so cheap). But this was part of my point, DVD's are too small for high-def backups, and *if* people have strategies similar to the grandparent post in terms of download only video instead of purchasing media direct, whatever media is more available for cheap burnable configurations will have a particular advantage.
I am of the opinion that disc purchasing isn't going anywhere due to streaming, unlike other people who think streaming obsoletes everything. Blockbuster and Netflix can worry about streaming and IPTV, pay per view, but places like Suncoast, Best Buy, Wal Mart have little to worry about yet. MP3s are popular in general because they are relatively short and audio only, hence very small and manageable on a few GB of storage for extraordinarily large storage. A single DVD can hold most people's entire movie collection. Let's assume a movie collection would be 4 GB per movie and 1 movie per 3 album. 3 albums would be about 180 MB. If that rough guesstimate held, storage would have to be about 120 GB before I would think saveable streams should worry movie publishers.
It's probably will happen, but it's a ways off before 120GB storage flash parts, mini hard drives, or single disc optical media capable of that will be out.
I feel just bizarre saying Blu-Ray all the time.
And I stand very much corrected on the laser wavelength issue. For some reason I keep seeing that posted as a HD-DVD advantage.
1TB will be a single drive soon, anyway.
I shall mock you when that single drive fails.
Seriously though, most people using computers know that drives fail and they risk losing everything on there, so they will want to back up purchases to relatively cheap media (optical media fits the bill). So you would still have an optical media competing for dominance, just in a slightly different way.
Mirroring and Striping with parity alleviate the issue of hard drive failure, but don't guard against software screw ups, bad software, or bad user mistakes.
Also, try playing your media library in your car for passengers. And don't say buy different media for home and car use, that would just be silly. If users didn't want their movies to be easily mobile and weren't adverse to putting their eggs in one basket by storing them on a disk array, they are probably happy with pay-per-view movies delivered over an infrastructured architected with this very purpose in mind.
This is the view of the lion's share of the market. I too usually just plop in a disc and rip to array, but I also like having the media available in case of storage subsystem failure of any sort.
BD-ROM drives logically have everything physically needed to do both formats. Ergo, BD players probably will feature cross-compatibility at some point (it already will have two lasers for legacy discs anyway). Maybe they'll have a unified laser device that changes the requirement for two lasers for new and legacy support.
HD-DVD only drives will be significantly easier to produce, using the same wavelengths as today. HD-DVD drives therefore can probably go lower in price.
So you'll end up with a market of HD-DVD only players, and players that will blay both HD-DVD and BD-ROM.
So studios logically pick HD-DVD because everyone can play it. Just ask OS/2 how supporting the competing standard as well as your own works when your competition does not return the favor..
The PS2 can play DVDs but precious few people use that feature that I know. PS2 using DVDs really doesn't affect the rest of the world except to mean that PS2 games will be DVD... True that DVD has no competition and was established well before PS2 came along, but it illustrates the point that people aren't too big on unified devices.
PSP is out and for a short while there was a fair amout of success around UMD movies. Novelty wore off quick and again, no one cares and the significance of UMD is not that movie studios care to support UMD, but PSP games are done on UMD. This is without an affordable similar alternative (video iPod is the only other thing reasonably in the market, and even then it isn't quite the same).
PS3 will use BD-ROM. That means games for PS3 will be Blue Ray. Depending on the cost and library available for Blue Ray and HD-DVD at the time of PS3 launch, the feature will probably be a moot point. If there is even a modest library of titles for HD-DVD and a player could be had for ~100 bucks, the BlueRay aspect of PS3 will be a moot point one way or the other. It *could* have an impact if all HD-DVD players and Blue Ray players on market are still around 500 dollars or more, or if the library of both were negligible. In essence, entering a market without reasonable competition before any market penetration has occured, since PS3 would be cheaper than buying a console *and* a movie player. If a separate player is under $100 bucks few will care about the movie playing feature of PS3.
I've only gotten my HD mythtv setup to 'crazy', acheiving 'mad crazy' is a huge step in the right direction.
Seriously though, not that hard. I have a box that does ATSC and mythtv and displays via DVI to HDMI cable to my TV. (AirStar HD5000 tuner, onboard GeFore 6150 for DVI video). It could do unencrypted QAM channels if I wasn't too much a cheapskate to buy cable.
I would be impressed if they had something that took CableCard or something for encrypted QAM channels on cable.
30 Watts could be clunkily done via a direct attach cable from PSU. Cooling probably is a fair issue, most accelerators in the market today don't have that much heat to dissipate, therefore meeting PCI-spec like requirements with a cooler is an issue for 1U systems that don't allow multi-width cards at all. Conjecture had been that the DIMM sockets were not being utilized, and that was my chief concern about a device sitting in that spot and crippling the memory capacity. HTX slot is fairly standardized and becoming more prevalent in the market, so building a single board isn't that much of a challenge, though some 940 platforms admittedly do not have that slot.
The other issue is how does it deal with other devices that may be connected via hypertransport to the socket it occupies? For example one strategy I see pursued to get more inter-node IO is to have, for example, a four socket opteron where each socket has two links to two processors and the third brought out for inter-node IO via PCI-E chips or HTX.
It could be interesting compared to clearspeed offerings, but the platforms I work with have moved on to AM2 for the future...
Might as well make it an HTX card rather than suck up a CPU socket that could otherwise be driving more memory (picture implies no attached memory). Most upcoming 940 platforms have HTX slots now for the equivalent performance/latency with a left over hypertransport links.
Just to make clear what is required...
We can have it to 15 GB/s for most conversation (because he implied concurrent read/write, and most people just discuss unidirectional bandwidth)
That brings us down to about 150-170 Gb/s required to measure a cross-sectional bandwith of 30 GB/s.
So, say, a 256 node cluster running something like GPFS or Lustre even on gigabit ethernet might play in the realm of 30 GB/s concurrent read-write throughput. This is assuming nodes contributing their storage to a pool and not having any SAN-like sharing which would mean a bottleneck there.
256 node clusters, while not common, would not surprise me to be under the administration of a handful of slashdot readers.
One, the price of all this stuff is exhorbitant, and most home applications could barely benefit from going from 100 MBit to Gigabit. Realistically, getting 1.5 microsecond latency and the ability to transfer GigaBYTES per second has no home use right now. Really exorbitant High definition streams top out at about 20 MBit/second for 1920x1080 MPEG-2, and of course no game demands that much throughput. Hard drives for home use can only theoreticly dump out 300 MB/s or so anyway (SATA II), and realistically except for cache operations you almost never acheive it.
Going to gigabit ethernet makes diskless systems close to theoretically working as fast as UDMA 66 drives, which allows for fun home projects working more smoothly. Latency for network operations is already similar to drive seek times, so going to insane latency won't help too much either.
Systems that benefit from this have to have large (many-drive) storage architectures to pull throughput from and large numbers of systems to have enough computational data to make the interconnect fabrics worth while. Before you begin to ever approach a system that large, your power/cooling bill would be insane.
If you were into the intrensic interesting stuff of this, you can learn most principles involved with good old ethernet, and fill the gaps with google research. It is undeniable that you learn more hands on, but if you ever really need to use it with a company or something and you have your bases covered, chances are you'd exceed most other candidates who aren't even aware of the technology.
For those not aware of how ethernet is limited latency wise regardless of what is done, I will explain a tad.
Ethernet is well architected for large deployments (enterprise-wide) with the packet routing (not IP routing) done on the switches. Menaing a computer sending a packet asks its switch to get it to 0A:0B:0C:01:02:03, having no idea where it will go. Switch only knows it's immediate neighbors, and will check/populate it's arp table to figure out the next entity to hand off. This means switches have to be really powerful because they are responsible for a lot of heavy lifting for all the relatively dumb nodes. This is not TCP, it is not IP, it is raw reality of ethernet networking. Aside from Spanning tree (which is not maintained for any other reason than keeping a network from getting screwed over by incorrect connections, not for performance), no single entity in the network has a map of how things look beyond its immediate neighbors.
IB, Myrinet, etc, are source routed. Every node has a full network map of every switch and system in the fabric. The task of computing communication pathways is distributed rather than concentrated (fits well with the whole point of clusters). node1 doesn't blindly say to the switch, 'send this to node636', it says to switch 'send this to port 5, and the next switch, put it out port 2, and the next switch, do port 9 and then it should be where it needs to be'.
There are more complicated issues their, but a lion's share of the inherent strength of non-ethernet interconnects is this.
Lately, the big contenders are:
-Ethernet
-Inifiniband
-Myrinet
I haven't heard much about SCI or Quadrics lately, and just these three have been tossed around a lot lately. Points on each:
-Ethernet is cheap, and frequently adequate. Low throughput and high latency, but it's ok. 10GbE ethernet is starting to proliferate to eliminate the throughput shortcomings, and RDMA is starting to possibly help latency for particular applications. Note that though overwhelmingly clusters put together using ethernet use IP stack to communicate over it, it is not exclusively true. There are MPI implementations available that sit right under the ethernet header layer. It bypasses the OS IP stack which can be very slow and reduces overhead per message. Increasing MTU also helps throughput efficiency. But for now only 1 Gigabit ethernet is remotely affordable at any scale (primarily due to current 10GbE switch densities/prices, adapters are no more expensive than Myrinet/Infiniband).
-Myrinet. With their PCI-E cards they achieve about 2 GBytes/sec bidirectional throughput, very nearly demonstrating full saturation of their 10GBit fabric. They also are among the lowest latency sitting right about 2.5 microsecond node-to-node latency as a PingPong minimum. Currently the highest single-link throughput technology realistically available to a customer (Infiniband SDR doesn't quite acheive it, about 200 or so MByte/s short, but DDR will overtake it as it realistically is available). Very focused on HPC and until recently also the only popular high-speed cluster interconnect that was very mature, easy to set up and maintain, and efficient. Now they are starting to embrace more interoperability with 10GbE, probably in response to the rise of infiniband.
-Infiniband. Until very recently immature (huge memory consumption for large MPI jobs, software stack that is highly complex and not easily maintanable, and the prominent vendor of chips (Mellanox), didn't acheive good latency. With Mellanox chips you are lucky to get into the 4 microsecond range or so. With Pathscale's alternative implementation (particularly on HTX), the lowest latency interconnect becomes possible (I have done runs with 1.5 microsecond end-to-end latency even with a switch involved). The maximum throughput is on the order of 1.7-1.8 GByte/s and more importantly is one of the faster technologies in ramping up to that. No technology acheives their peak throughput until about 4 MB message sizes, and Pathscale IB is remarkably a good performer down to 16k-32k message sizes. Additionally, IB has a broader focus and some interesting efforts. They make efforts to not only be a good HPC interconnect, but also to be a good SAN architecture that in many ways significantly outshines fibre channel. The OpenIB efforts are interesting as well. The huge downside is that for whatever reason no Infiniband provider has been able to demonstrate good IP performance over their technology. This particularly is an issue because most all methods of storage sharing from hosts are IP based. SRP is ok for the little amount of flexibility that strategy gives to be Fibre-Channel like, but nfs, smb, and image access like NBD and iSCSI all perform very poorly on Infiniband compared to Myrinet. iSER promises to alleviate that, but for the moment you are restricted to performance on the order of 2.4 gigabit/s for IP transactions. Myrinet has been able to deliver 6-7 Gigabit/s for the same measurements. You could overcome this by sharing storage enclosures and use something like lustre, GFS, or GPFS to communicate more directly with the storage over SRP, but generally speaking some applications demand flexibility not acheivable without IP performance.
And at the end of the day, I come home and run my home network on 100MBit ethernet, sigh. It is enough to run a diskless MythFrontend for HD content at least.
First, erase any reference to the announcement from the internet (Google can do anything, right?)
Second, utilize your Jedi to complete the 'unannouncement'
(hand wave)This is not the announcement you are looking for.
I think it's easy to say Star Control 2 was the definiitive game for the continued fame of Star Control. I'll also say that the PC version is the one people really got, and the 3DO's only legacy is being the one that they still had source code to make UQM a reality.
With this in mind, I would say their target market would be largely comprised of those who were around and immensely enjoyed Star Control 2. While probably many of that market have game consoles of some variety, they all are probably more likely to be heavily into their computer. People who played DOS games in the 90s generally were consistantly computer oriented, probably because it was more of a hastle back then for so many games that required x amount of conventional memory and you had to fiddle with things to get rid of memory resident things not needed for that game and move whatever else you could to 'high memory'. Those were the days...
Anyway, considering the bulk of their target market would be those who already played SC2, the platform that makes sense is personal computers. To go a step further, it should be cross-platform and run on at least Linux/x86 and Windows. Though I don't have definitive evidence for it, I strongly suspect large portions of SC2's fanbase is on linux and that uqm usage statistics may be enlightening. Additionally, developed correctly it isn't that hard to make even a fairly sophisticated game run on different Operating systems, so the cost/benefit ratio should be good regardless.
It's hard looking at their list of games to establish them to now be console-only, they haven't developed enough games, and none of them have been notable enough compared to SC2. Their best bet if they had the opportunity to do a sequel would be to target their old fans as closely as possible. If it is a good game, it would be a nice revival for their name which hasn't seen a big title since 1992.
AMD also has SSE2 for most recent cores and SSE3 for Venice and up. AMD embraces every extension intel produces, it is intel that has no interest in some AMD extensions (3dnow). However, Intel did certainly embrace AMD64 (of course not calling it that...) At least I haven't heard of intel system doing that.
My intel system flags (Pentium M):
fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
My most recent AMD system (pre-venice):
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt 3dnowext 3dnow
It is of course true that whichever vendor has an extension released there is a short time in which it is exclusive to their product line, but it doesn't last long. I think AMD and intel have a long standing cross-licensing agreement that precludes either from locking out the other from new instructions/instruction sets.
1) If you are considering the virus' validity all by itself, it doesn't matter what language it is in. If you are considering it as a proof of concept for a new type of virus, the detail of it being written in assembly is a) not as damming as you portray and b) probably not indicative of a requirement going forward.
.exe. Now there are a lot of precautions to prevent this in an up to date Windows system, but architecturally this is how it happens. In linux, the permissions dictate and the permissions are not transferred with the file content (unless encapsulated by something like tar). gnome-open a potentially executable file without the executable permission and nothing interesting should happen.
2) This is what *really* made me have to reply. You must have *no* idea of what exactly is ELF on a linux box. Every compiled application in the last 10 years or so has been almost exclusively ELF. Without ELF support, you simply don't have a working modern distribution. You could theoretically try to run the old a.out format, but that really isn't any more safe in the long term and highly impractical.
3) Again, the important aspect is 'proof-of-concept' This particular virus doesn't bother to attempt chdir.but that does not preclude the concept of more general implementation. But the rest of what you say is applicable. Once I would have said an inexperienced user frequently only bothers to run as root, since it makes things easier, but with the proliferation of strategies like Ubuntu, things are handled a lot more sanely. The lesson they learned is not to ask a typical user for a root password at *all*, lest they be tempted to use it for everything.
It is conceptually hard to see this thing spreading. The stategy of spawning from ELF applications means it has to be set executable by something prior to being run. In Windows they historically accomplish the analagous function by leveraging the weak strategy of filename based executable status and the 'friendly' feature of hiding extensions that only sometimes work, and you have 'nicepicture.jpg.pif' or something similar that a Windows app lazily hands the file over and then Windows make the lazy choice of honoring
Again, as non-root usage for even the lazy users increase, this strategy with respect to propogation becomes irrelevant as few users run applications capable of relaying the content that they would also have write access to. Now if by some miracle infected by a virus of this type with goals other than spreading, it can be almost as functionally devastating, despite the privilige separation. For the same reasons that the system files and other users are protected from a particular users activity, most of a single-user machine's important data is owned by the user. Sure, if attacked they could make a new user unaffected without reinstall as worst case, but they may have lost all their documents, records, and images they actually care about that aren't recoverable.
The net of it is that the stuff important to a desktop user is not protected from viruses, but the traditional executable binary approach of viruses just doesn't apply to linux. Exploiting buffer mismanagement and such in media players, document readers, image renderers, etc *are* applicable in linux as well as Windows and this would be the only sort of virus that I would watch to be a remote success. This strategy doesn't try to dance around the strong impedements at the low level architecture, but exploits the much more likely poorly coded app given permission to run legitimately by the low level platform.
Well, one, many applications can work in a very heterogeneous environment, if the work is divided correctly. The easiest examples are protein folding where each system can work an individual protein, and the faster ones don't need to wait to get more work units, rendering, breaking encryption, certain types of physics simulations.
Now let's assume you have an application where you can't efficiently divide the work such that there is no intrinsic codependency between node work, and that what you say holds, that the slowest node dictates performance for the whole cluster. The simple workaround is to have the number of jobs running on nodes be asymmetric. I.e. you have 6 systems at 1 GFlop/s each and 6 at 2 GFlop/s each. So on the first 6, run 1 'thread' per node, on the latter 6, run 2 threads per node. It would of course be more complex depending on the characteristics of the node and job, but generally if an application can be scaled to arbitrary number of nodes for computing, you can scale it asymmetrically. Of course, be sure the other subsystems of each node are sufficiently good to handle twice the workload, particularly memory.
Would massive surface mirrors be a more feasible solution? Many floating mirrors in the oceans, on roofs of buildings/houses/etc. That Time magazine scare piece on global warming had me wondering about that as one of the things mentioned was that a massive diminishing ice surface is a feedback loop. As it gets warmer, ice melts to water and as the surface area of the ice decreases in favor of non-reflecting water, the Earth absorbs rather than reflects more. If scientists stating decreasing ice surface area has an affect are correct, it stands to reason that adding more surface that is even more reflective would have the opposite effect. Sure it is within the atmosphere and therefore would mean the atmosphere sucks up more than the extra-planetary sort of solution, but it would be much more in reach without affecting solar output for everyone across the world (and by extension reducing the prospect of solar energy where applicable).
I would think a mirror surface that is completely reflective would be most effective, but light colored surfaces would have some effect as well.
The Top500 benchmark is double precision floating point operations, 64 bit. The platforms boasting seemingly unbelievable teraflop figures are flaunting single-precision (32-bit) performance. Though still boasting Rpeak when only Rmax really counts (theoretical maximum versus acheivable performance), it isn't an outright lie, just not taken in the same context as Top500.
Sometimes it is valuable to have a good team that doesn't need to be led.
Wherever I go, I've found in decent sized organizations the ones that look the least presentable but have managed to stick around a few years are among the best. Not because of anything intrinsic about the unkept look, it is because those are the ones that are good enough that the uptight suits couldn't justify firing in a million years *despite* the look that really rubs them the wrong way. If you don't dress very well and aren't bulletproof with respect to your technical merits, uptight suits up higher will find a reason to replace you with a more visually acceptable candidate, even if technically they aren't quite as good.
That just reflects people looking for info about a platform, has nothing to do with people running the distros, just what is popular to read about and think about and, to some extent, a popular choice for newcomers, not for those established with a distro already.
An analogy would be to look at how many people search for, say, a Ferrari versus how often people search for a Ford Focus. The Ferrari are more interesting and people search for them, but doesn't mean that the proportion of Ferrari drivers to Focus drivers is anywhere near what google search statistics would suggest with this methodology.
Having 20-30 booths worth of papor ballots counted by one electronic scanning machine is cheaper than 20-30 computers with touchscreens, period. Having the paper trail to attempt to audit is important for political reasons if not technical reasons. It's much harder to tamper with paper ballots than paper ballots at scale. True, their is nothing technically difficult about modifying a single ballot paper wise, but modifying thousands of ballots *and* coordinating such an effort with electronic vote counting machine tampering is far more difficult than tampering with any purely electronic database of votes. Would be fraud would have to be more sophisticated than if just having paper or electronic voting.
Manual paper ballot counting almost never occurs, so it isn't fair to put that counting time into the equation across the board.