Too many developers with CS degrees, too few with SE degrees, and nearly none with IS degrees. See http://www.acm.org/education/c... for more details on the differences.
According to the ACM (you know, the experts in this topic), there are five basic courses of study: Computer Engineering (making the hardware) Computer Science (designing the algorithms) Software Engineering (release processes, patch management, etc) Information Systems (translating business processes to code) Information Technology (putting all the pieces of the system together an maintaining the whole lot).
Make sure you refresh those PROM's if they're EPROM or EEPROM (the absence of a window is no indication that it's a real fusible link PROM; it could be OTP UV EPROM in there). There is a thing called bit rot that occurs with most EPROM/EEPROM/Flash technologies where the isolated gate's charge bleeds off over time; 20 years is fairly normal, but 30 and 40 year old EPROMs (1702, 2708, and 2716 era) are beginning to fail all over. Search through the http://www.vintage-computer.co... forums as well as read the Wikipedia article ( https://en.wikipedia.org/wiki/... ) to learn more.
Mask ROMs are better, but not perfect. If the package is a 40 pin DIP it's almost sure to be flash, and that will bit-rot over time.
One more item on the checklist are those old paper caps that need to be replaced by X-class film on the inputs to power supplies. Again, the Vintage Computer forum is a great resource for information on how these things fail.
Also any batteries for NVRAM, like the ubiquitous Dallas Semiconductor devices, many of which are soldered in place. Or soldered in Lithium primary cells. Or like many older PC motherboards that have NiCd or NiMH cells that are both soldered in and leaking electrolyte. We have some Proteon routers (cisco's competitor back in the day) that have their NVRAM as low-power CMOS statis ram with a large bank of NiMH cells on a multibus card; they've long since lost any ability to retain charge.
As electronics age, lots of issues arise, and anyone who maintains such a system needs to see how others are handling the failures in these sorts of systems; again, the Vintage Computer forum is a great resource of talented people who are dealing with equipment of the same age. I know of many systems, particularly scientific instruments, where the controls are things such as a VAXstation 4000/90 connected to a SCSI CAMAC crate with wirewrapped boards, and VME Sun 2 and 3 series workstations controlling the whole lot. Keeping an aging VAXstation with VMS 5.2 or similar vintage running, with those old DEC StorageWorks 2GB and 4GB narrow SCSI drives, is a bit of a challenge, but when you have custom controls for multimillion-dollar equipment with no spares budget or major research instrumentation upgrade grant you have to get creative. (No, you can't just throw a PC in there, since the entire system's calibration depends upon the whole system timing and not just the actual platform). This system is being upgraded (there was even slashdot story about the upgrade at http://science.slashdot.org/st... ) but it's expensive to do things to the precision required.
Also, if the system uses GAL's or EEPROM-based FPGAs/CPLDs this is also something to make sure you have backups of the logic (JEDEC files, typically). Even fusible link PALs can go south. And be sure to have a stock of replacement chips, since many if not most of those older devices are long out of production.
Lots of test equipment is in this same boat, with expensive instruments like spectrum analyzers and the like running embedded MS-DOS and Windows on hard drives that are going on 20 years old. And, yes, in many cases they are consumer hard drives (I just looked at a very expensive 'multipath fading simulator' device, and it has a 6.4GB Western Digital Caviar drive in it.... you remember those? And one instrument I haven't looked into in a long time uses a 170MB Micropolis 5.25 full height ESDI drive.....
Don't know how many astrological discoveries there may be, since astrology looks into the future and this is looking into the past. But I do get the reference......
The difficulty with merging images could be the sparse nature of the data on the plate. In doing something like the visual6502.org dieshots there's plenty of data with which to do tiling; astronomical imagery is pretty sparse. So, while tiling will likely have to be done, the basic accuracy and precision of the platform (including the flatness and purity of the camera optics) is very important, and quite expensive.
Yes. Required for the stability to scan with the precision and accuracy needed for both astrometry and spectroscopy. You need zero backlash positioners and a rock-solid (pun intended) surface.
Less expensive than the alternatives, such as refitting a PDS 2020G such as was used to generate Space Telescope Science Institute's digitized sky survey ( https://en.wikipedia.org/wiki/... ).
Yeah, reading Slashdot just isn't what it used to be. It, freshmeat.net, and linuxtoday.com were three of the sites I began reading in 1997 prior to putting up a new server install online..... of Red Hat Linux 4.1.
I forget when I registered, but it was a while after I had started reading it.
The only deal with a low id is that you have to maintain ancient e-mail addresses to keep it.....
So, the beta leaves a lot to be desired. But that's partly why it's beta, no? (and, no, I'm still on classic, and plan to stay that way as long as possible.)
One of the big slowdowns for getting 6.0 out the door was getting 5.6 and 4.9 out the door.
I have rebuilt CentOS 5 from source on Itanium (IA64) and the step from 5.5 to 5.6 was rather interesting, and took a lot of thought as to which versions of certain libraries would build properly and needed to build properly in a very specific order (I don't recall right off hand the details, since it's been over a year since I did it, but there was a fairly substantial library uprev about halfway through the rebuild that had to be built after a few packages but before a few others; it was substantial enough that some of the packages in the first half would not rebuild at all with the newer version, and packages in the last half had to build with the newer version).
And EL6.0 was a beast to bootstrap, requiring a frankendist mix in the buildroots. I have not, and am not planning to, bootstrap it on IA64; Red Hat does do an IA64 for RHEL 5, but not for 6, so the source hooks and patches for IA64 were already in the source RPMS for 5, but are not for 6.
The members of the CentOS team have learned a great deal since then; I honestly think they got caught flatfooted by 6.0, but that's just my (very possibly incorrect) opinion.
Yes, it should be good. I look forward to watching it, to see if either come up with any new arguments.
As to all the typical slashdot anti-creationism drivel, well, there are many logical and rational ways to talk about the various forms of creationism.
All science and math have to start out with postulates or axioms; things such as Euclidian geometry and spherical geometry, for instance, start out with axioms that simply cannot be proven, and these two exemplars each derive a useful system of geometry with contradictory axioms.
Evolution in general and neo-Darwinism in particular take as axiomatic that there is no creator and all things happened through the action of random chance, that is, the creation of order through stochastic processes, beginning with a single lifeform (common ancestry).
Creationism in general takes it as axiomatic that there was a creator, and things happened through that creator's initial action plus the actions of the various laws established through said creation.
In fact, it could easily be said that the creator was the Cosmic Egg (that of the Big Bang, you know, not that of various ancient middle eastern religions), since there is no way to go back past this event for which there is ample evidence (the cosmic background radiation, for instance).
It is impossible to disprove that a creator acted 6,000 years ago and made an old earth. It is also impossible to prove that a creator acted 6,000 years ago and made an old earth, too. For that matter, it is impossible to prove without any axioms that yesterday even existed. All proofs start with postulates, and all postulates and axioms are irrational. Irrationality is not a bad thing; just ask pi, e, and various square roots.
Axioms and postulates require faith in them, since they (by definition) cannot be proven.
As a thought experiment, put yourself in the postulated creator's shoes. You are getting ready to make the first trees; ok, how many rings to you put in them? Or in making a horse, what about the horse's teeth? Does the first man have a navel? All of those things are evidences of a past and of the passage of time; yet, if you create a tree today that has fifteen rings, your created man (created a couple of days later) could core into this tree and falsely state that it is 15 growing seasons old. You, acting as the creator, are making an old tree. Extrapolate to an old earth and an old universe.
My problems with evolution are that, even with the reams of evidence for microevolution, there are many more holes in the theories of macroevolution than there is evidence. For instance, the supposed primordial soup of the young earth can create amino acids; this much has been demonstrated in the laboratory. Oh, good, you have the building blocks of protein. Ok, mRNA can be synthesized in such an enviroment. That's good, now you have the blueprints for protein. But protein synthesis in even the simplest living cell requires more than a soup of assorted amino acids and mRNA (along with tRNA, rRNA, and DNA); other already synthesized protein 'machines' (ribosomes, for one) are required to do the kind of protein synthesis found in real cells (after all, a virus is basically those two things, a protein container with mRNA or other genetic material as a payload that hijacks already existing cells' protein synthesis machinery to build more viruses). Where is the evidence of each and every step required to make the first single celled organism? I would say 'simple' single celled organism, but in reality even the simplest single celled organism is massively complex.
There are lots of holes; until the holes are filled the theory is not proven.
Now, again, microevolution is readily observable and without doubt. But what about the most macro of the macroevolution foundation stones, the initial evolution of the first single cell? And what about that cell's reproduction? Mitosis is insanely complex at the molecular level.
wsusofflineupdate ( www.wsusoffline.net )works well; use one machine to download everything, generate an ISO or USB key with the updates, and update offline.
The Sinclair ZX80 and 81, and the TS1000, were really neat machines. The Z80 did double-duty in those, and directly drove the display (FAST and SLOW modes, with FAST being, well, a bit odd). The keyboard was, well, a bit odd is putting it mildly.
My first home computer was a VIC-20, primarily because the TS1000's keyboard was so bad, but I couldn't afford the TRS-80 Model III that I really wanted. The VIC-20 and C64 had real keyboards, and that was a very big deal. The membrane keyboard of the TS1000 was not good at all. But I was and am a Z80 assembler programmer to the core, and so while I had and used the VIC-20 a lot (even built my own memory expansion card with 1Kx4 (2114) static RAM chips) I never really got into 6502 assembler coding.
Further, North Carolina has one of the world's premier research and education networks, NCREN ( http://ncren.net/ ), which just underwent significant expansion over the last two years.
And the list of high-tech and higher education excellence goes on and on.
North Carolinians even know about Slashdot.:-)
Having read the actual article, and not the biased summary, it seems a reasonable decision for the director to make. There is a place for that type of documentary; and it would certainly be a good thing to show in the right venue. And I'm sure the director had a difficult time with the decision.
But, then again, just exactly what does Slashdot commentary have to do with the scientific process anyway? (Yes, I do understand real science, and I also don't have any need to prove that to anyone).
There are a few folks that have looked at it. It will likely be difficult to do, as you'll need to bootstrap your way up from the corresponding Fedora releases, beginning, IIRC, at Fedora 9 (that's the last Fedora with IA64 support).
So you'd probably need to start at F9, and chronologically build F10, F11, F12, and F13. C6 is based off of a mix of F12 and F13. Oh, and major things happened between F9 and F10. The tool that sits at the guts of this is called mock, but it's a bit 'fun' to get started with. 'Chronological' in this case means by source RPM build timestamp. You'd start with a minimal buildsystem, and get that up to the desired release, then build the other packages. Mock makes this sort of build relatively straightforward, but it won't hold your hand and figure out for you when you need to rebase the buildhost itself. Oh, and while Fedora does have a stated goal of being self-hosting, RHEL does not. This is part of the reason it took so long for the RHEL rebuild projects to get version 6.0 out the door.
Complicating things is the fact that you're going to be on your own with any patches you need to make to the upstream source; when upstream (Red Hat, in this case) is supported an arch it's not too bad; but RHEL6 has no IA64 in the source, and with the kernel especially that might be hard.
To give a rough benchmark, just getting from Scientific Linux/CERN 5u4 (the last free RHEL rebuild for IA64; CERN dropped it at that point, even though Red Hat still builds for IA64 on EL5) up to CentOS 5.8 took close to a month of build time. I've built 5.9, and have 5.10 on my plate. With IA64 support in the source it's pretty mechanical, but even then there are challenges. Like composing install media, which I've not done as yet (I've just used the SLC5.4 install media, then rebased the repos to my own C5 repos, and used yum to update over to C5).
Again, the biggest stumblingblock to C6 on IA64 is going to be maintaining any IA64-specific source patches, both in the build spec files and in the sources themselves.
But feel free to get involved.:-)
Otherwise, Debian is a good alternative, but with the mainline kernel losing support for IA64, it might get tough.
I have the manpower to maintain our own in-house CentOS 5/IA64, but not to bootstrap C6 onto IA64.
MIPS V apparently never actually hit silicon. R10K, R12K are still MIPS IV. (I have some SGI kit with those, a couple of the purple Indigo2 IMPACT systems, and an O2.....)
If you're thinking MIPS64, well, you can find that in embedded devices, routers, etc. Look for Cavium Octeon processors.
Red Hat Enterprise Linx 5 is still available and supported for IA64. At least at the moment; this will give IA64 users a Linux soure base at least until 2017.
I have personally rebuilt CentOS 5 from source for SGI Altix, which is an IA64 box, and am running a smallish Altix (30 CPU's, 54GB of RAM) in production for data analysis. (NASA's Columbia supercomputer was an IA64 Altix with 10,240 CPU's.....)
[I know I'm a day late....] Harrison Mixbus. Commercial Ardour-derivative with fantastic sound, put out by Harrison Consoles, manufacturer of seriously high-end hardware. See http://www.harrisonconsoles.com/mixbus/website/ for its website. Runs natively on Windows, Max OS X, and Linux, and pretty much equally well on all three (runs best, IMO, on Linux, but I use it most on OS X due to some plugins I like).
Today's caviat is that I admit not knowing how much OS X 10.8 cost off the shelf.
I paid $19.99 for both Lion and Mountain Lion, straight from the App Store (need to be at 10.6.8 first). Snow Leopard was a bit more expensive; I think it might have been $29.99 for the DVD. Leopard and prior were (and are, on eBay at least) quite a bit more than that.
You have a point, but you lost credibility when you included OTA in that list. OTA is uncompressed 18.2mbit MPEG.
You lost credibility when you called MPEG 18.2Mb/s 'uncompressed.'
True uncompressed 1080p 24-bit color video requires a bit over 1.4Gb/s of bandwidth (do the math: 1920x1080 pixels; 24 bits per pixel; 30 frames per second = 1,492,992,000 bits per second.
18.2Mb/s is 82:1 compression. The discrete cosine transform is good, but not good enough to yield lossless compression of the video if you're constrained to a fixed bitrate. Especially in poor signal areas. And the typical 'HD' OTA station will only use 7Mb/s for their 'HD' output.
Uncompressed 720p video fares a bit better, only requiring 1366x720x24x30 = 708,134,400 bits per secons (around 700Mb/s), and so that typical 7Mb/s HD stream is actually 100:1 compressed (it's near lossless, and with static, blocky, content it can be completely lossless, but rapid motion means lost bits and a lossy section of the compression for a fixed bitrate. And so you see artifacts; grass, with its texture, is a near worst-case scenario for the DCT-based codecs, and so artifacting on grass is most definitely worse.
The 2008 revision of ATSC includes H.264 as a codec; I can 'see' H.264, and, like the GP, it does bother me.
Slashdot Mirror
Too many developers with CS degrees, too few with SE degrees, and nearly none with IS degrees. See http://www.acm.org/education/c... for more details on the differences.
According to the ACM (you know, the experts in this topic), there are five basic courses of study:
Computer Engineering (making the hardware)
Computer Science (designing the algorithms)
Software Engineering (release processes, patch management, etc)
Information Systems (translating business processes to code)
Information Technology (putting all the pieces of the system together an maintaining the whole lot).
You can read more at the ACM (Association for Computing Machinery) at http://www.acm.org/education/c...
Make sure you refresh those PROM's if they're EPROM or EEPROM (the absence of a window is no indication that it's a real fusible link PROM; it could be OTP UV EPROM in there). There is a thing called bit rot that occurs with most EPROM/EEPROM/Flash technologies where the isolated gate's charge bleeds off over time; 20 years is fairly normal, but 30 and 40 year old EPROMs (1702, 2708, and 2716 era) are beginning to fail all over. Search through the http://www.vintage-computer.co... forums as well as read the Wikipedia article ( https://en.wikipedia.org/wiki/... ) to learn more.
Mask ROMs are better, but not perfect. If the package is a 40 pin DIP it's almost sure to be flash, and that will bit-rot over time.
One more item on the checklist are those old paper caps that need to be replaced by X-class film on the inputs to power supplies. Again, the Vintage Computer forum is a great resource for information on how these things fail.
Also any batteries for NVRAM, like the ubiquitous Dallas Semiconductor devices, many of which are soldered in place. Or soldered in Lithium primary cells. Or like many older PC motherboards that have NiCd or NiMH cells that are both soldered in and leaking electrolyte. We have some Proteon routers (cisco's competitor back in the day) that have their NVRAM as low-power CMOS statis ram with a large bank of NiMH cells on a multibus card; they've long since lost any ability to retain charge.
As electronics age, lots of issues arise, and anyone who maintains such a system needs to see how others are handling the failures in these sorts of systems; again, the Vintage Computer forum is a great resource of talented people who are dealing with equipment of the same age. I know of many systems, particularly scientific instruments, where the controls are things such as a VAXstation 4000/90 connected to a SCSI CAMAC crate with wirewrapped boards, and VME Sun 2 and 3 series workstations controlling the whole lot. Keeping an aging VAXstation with VMS 5.2 or similar vintage running, with those old DEC StorageWorks 2GB and 4GB narrow SCSI drives, is a bit of a challenge, but when you have custom controls for multimillion-dollar equipment with no spares budget or major research instrumentation upgrade grant you have to get creative. (No, you can't just throw a PC in there, since the entire system's calibration depends upon the whole system timing and not just the actual platform). This system is being upgraded (there was even slashdot story about the upgrade at http://science.slashdot.org/st... ) but it's expensive to do things to the precision required.
Also, if the system uses GAL's or EEPROM-based FPGAs/CPLDs this is also something to make sure you have backups of the logic (JEDEC files, typically). Even fusible link PALs can go south. And be sure to have a stock of replacement chips, since many if not most of those older devices are long out of production.
Lots of test equipment is in this same boat, with expensive instruments like spectrum analyzers and the like running embedded MS-DOS and Windows on hard drives that are going on 20 years old. And, yes, in many cases they are consumer hard drives (I just looked at a very expensive 'multipath fading simulator' device, and it has a 6.4GB Western Digital Caviar drive in it.... you remember those? And one instrument I haven't looked into in a long time uses a 170MB Micropolis 5.25 full height ESDI drive.....
Don't know how many astrological discoveries there may be, since astrology looks into the future and this is looking into the past. But I do get the reference......
The difficulty with merging images could be the sparse nature of the data on the plate. In doing something like the visual6502.org dieshots there's plenty of data with which to do tiling; astronomical imagery is pretty sparse. So, while tiling will likely have to be done, the basic accuracy and precision of the platform (including the flatness and purity of the camera optics) is very important, and quite expensive.
Hebrew for 'Mountain.'
Yes. Required for the stability to scan with the precision and accuracy needed for both astrometry and spectroscopy. You need zero backlash positioners and a rock-solid (pun intended) surface.
Less expensive than the alternatives, such as refitting a PDS 2020G such as was used to generate Space Telescope Science Institute's digitized sky survey ( https://en.wikipedia.org/wiki/... ).
Yeah, reading Slashdot just isn't what it used to be. It, freshmeat.net, and linuxtoday.com were three of the sites I began reading in 1997 prior to putting up a new server install online..... of Red Hat Linux 4.1.
I forget when I registered, but it was a while after I had started reading it.
The only deal with a low id is that you have to maintain ancient e-mail addresses to keep it.....
So, the beta leaves a lot to be desired. But that's partly why it's beta, no? (and, no, I'm still on classic, and plan to stay that way as long as possible.)
The same thing that stops them from using Red Hat's src.rpms.... that is, 'nothing whatsoever.'
One of the big slowdowns for getting 6.0 out the door was getting 5.6 and 4.9 out the door.
I have rebuilt CentOS 5 from source on Itanium (IA64) and the step from 5.5 to 5.6 was rather interesting, and took a lot of thought as to which versions of certain libraries would build properly and needed to build properly in a very specific order (I don't recall right off hand the details, since it's been over a year since I did it, but there was a fairly substantial library uprev about halfway through the rebuild that had to be built after a few packages but before a few others; it was substantial enough that some of the packages in the first half would not rebuild at all with the newer version, and packages in the last half had to build with the newer version).
And EL6.0 was a beast to bootstrap, requiring a frankendist mix in the buildroots. I have not, and am not planning to, bootstrap it on IA64; Red Hat does do an IA64 for RHEL 5, but not for 6, so the source hooks and patches for IA64 were already in the source RPMS for 5, but are not for 6.
The members of the CentOS team have learned a great deal since then; I honestly think they got caught flatfooted by 6.0, but that's just my (very possibly incorrect) opinion.
Binary compatibility does not mean that the checksums match.
It means that every binary RPM has the exact same library version linkages and dependencies.
Yes, it should be good. I look forward to watching it, to see if either come up with any new arguments.
As to all the typical slashdot anti-creationism drivel, well, there are many logical and rational ways to talk about the various forms of creationism.
All science and math have to start out with postulates or axioms; things such as Euclidian geometry and spherical geometry, for instance, start out with axioms that simply cannot be proven, and these two exemplars each derive a useful system of geometry with contradictory axioms.
Evolution in general and neo-Darwinism in particular take as axiomatic that there is no creator and all things happened through the action of random chance, that is, the creation of order through stochastic processes, beginning with a single lifeform (common ancestry).
Creationism in general takes it as axiomatic that there was a creator, and things happened through that creator's initial action plus the actions of the various laws established through said creation.
In fact, it could easily be said that the creator was the Cosmic Egg (that of the Big Bang, you know, not that of various ancient middle eastern religions), since there is no way to go back past this event for which there is ample evidence (the cosmic background radiation, for instance).
It is impossible to disprove that a creator acted 6,000 years ago and made an old earth. It is also impossible to prove that a creator acted 6,000 years ago and made an old earth, too. For that matter, it is impossible to prove without any axioms that yesterday even existed. All proofs start with postulates, and all postulates and axioms are irrational. Irrationality is not a bad thing; just ask pi, e, and various square roots.
Axioms and postulates require faith in them, since they (by definition) cannot be proven.
As a thought experiment, put yourself in the postulated creator's shoes. You are getting ready to make the first trees; ok, how many rings to you put in them? Or in making a horse, what about the horse's teeth? Does the first man have a navel? All of those things are evidences of a past and of the passage of time; yet, if you create a tree today that has fifteen rings, your created man (created a couple of days later) could core into this tree and falsely state that it is 15 growing seasons old. You, acting as the creator, are making an old tree. Extrapolate to an old earth and an old universe.
My problems with evolution are that, even with the reams of evidence for microevolution, there are many more holes in the theories of macroevolution than there is evidence. For instance, the supposed primordial soup of the young earth can create amino acids; this much has been demonstrated in the laboratory. Oh, good, you have the building blocks of protein. Ok, mRNA can be synthesized in such an enviroment. That's good, now you have the blueprints for protein. But protein synthesis in even the simplest living cell requires more than a soup of assorted amino acids and mRNA (along with tRNA, rRNA, and DNA); other already synthesized protein 'machines' (ribosomes, for one) are required to do the kind of protein synthesis found in real cells (after all, a virus is basically those two things, a protein container with mRNA or other genetic material as a payload that hijacks already existing cells' protein synthesis machinery to build more viruses). Where is the evidence of each and every step required to make the first single celled organism? I would say 'simple' single celled organism, but in reality even the simplest single celled organism is massively complex.
There are lots of holes; until the holes are filled the theory is not proven.
Now, again, microevolution is readily observable and without doubt. But what about the most macro of the macroevolution foundation stones, the initial evolution of the first single cell? And what about that cell's reproduction? Mitosis is insanely complex at the molecular level.
So the evolutionist must postulate that the s
wsusofflineupdate ( www.wsusoffline.net )works well; use one machine to download everything, generate an ISO or USB key with the updates, and update offline.
The Sinclair ZX80 and 81, and the TS1000, were really neat machines. The Z80 did double-duty in those, and directly drove the display (FAST and SLOW modes, with FAST being, well, a bit odd). The keyboard was, well, a bit odd is putting it mildly.
My first home computer was a VIC-20, primarily because the TS1000's keyboard was so bad, but I couldn't afford the TRS-80 Model III that I really wanted. The VIC-20 and C64 had real keyboards, and that was a very big deal. The membrane keyboard of the TS1000 was not good at all. But I was and am a Z80 assembler programmer to the core, and so while I had and used the VIC-20 a lot (even built my own memory expansion card with 1Kx4 (2114) static RAM chips) I never really got into 6502 assembler coding.
Good high school memories.....
Kriston!
Long live AOLserver!
White trash, eh? I know a few high-tech companies that would disagree with you.
You know, small companies that you've probably never heard of, like:
Google ( the Lenoir NC data center is featured: https://www.google.com/about/datacenters/inside/streetview/ )
Apple (Their Maiden, NC, data center is a model for green data centers: https://www.apple.com/environment/renewable-energy/ )
EMC (Not only do they have a huge datacenter/Center of Excellence in Durham, which earned LEED Gold status ( http://www.emc.com/about/news/press/2013/20130314-01.htm ) but they also manufacture storage arrays in their Apex plant ( http://www.emc.com/about/news/press/us/2006/08082006-4543.htm ) and have a significant R&D presence in RTP)
Facebook ( The Forest City Data Center: https://www.facebook.com/ForestCityDataCenter ) Oh, and Rutherford County is very rural.
Further, North Carolina has one of the world's premier research and education networks, NCREN ( http://ncren.net/ ), which just underwent significant expansion over the last two years.
And the list of high-tech and higher education excellence goes on and on.
North Carolinians even know about Slashdot. :-)
Having read the actual article, and not the biased summary, it seems a reasonable decision for the director to make. There is a place for that type of documentary; and it would certainly be a good thing to show in the right venue. And I'm sure the director had a difficult time with the decision.
But, then again, just exactly what does Slashdot commentary have to do with the scientific process anyway? (Yes, I do understand real science, and I also don't have any need to prove that to anyone).
They already do.
And be sure to watch the window size, the latency, and be very careful about too many dropped or NAK'ed packets.
Yes, it probably could.
There are a few folks that have looked at it. It will likely be difficult to do, as you'll need to bootstrap your way up from the corresponding Fedora releases, beginning, IIRC, at Fedora 9 (that's the last Fedora with IA64 support).
So you'd probably need to start at F9, and chronologically build F10, F11, F12, and F13. C6 is based off of a mix of F12 and F13. Oh, and major things happened between F9 and F10. The tool that sits at the guts of this is called mock, but it's a bit 'fun' to get started with. 'Chronological' in this case means by source RPM build timestamp. You'd start with a minimal buildsystem, and get that up to the desired release, then build the other packages. Mock makes this sort of build relatively straightforward, but it won't hold your hand and figure out for you when you need to rebase the buildhost itself. Oh, and while Fedora does have a stated goal of being self-hosting, RHEL does not. This is part of the reason it took so long for the RHEL rebuild projects to get version 6.0 out the door.
Complicating things is the fact that you're going to be on your own with any patches you need to make to the upstream source; when upstream (Red Hat, in this case) is supported an arch it's not too bad; but RHEL6 has no IA64 in the source, and with the kernel especially that might be hard.
To give a rough benchmark, just getting from Scientific Linux/CERN 5u4 (the last free RHEL rebuild for IA64; CERN dropped it at that point, even though Red Hat still builds for IA64 on EL5) up to CentOS 5.8 took close to a month of build time. I've built 5.9, and have 5.10 on my plate. With IA64 support in the source it's pretty mechanical, but even then there are challenges. Like composing install media, which I've not done as yet (I've just used the SLC5.4 install media, then rebased the repos to my own C5 repos, and used yum to update over to C5).
Again, the biggest stumblingblock to C6 on IA64 is going to be maintaining any IA64-specific source patches, both in the build spec files and in the sources themselves.
But feel free to get involved. :-)
Otherwise, Debian is a good alternative, but with the mainline kernel losing support for IA64, it might get tough.
I have the manpower to maintain our own in-house CentOS 5/IA64, but not to bootstrap C6 onto IA64.
MIPS V apparently never actually hit silicon. R10K, R12K are still MIPS IV. (I have some SGI kit with those, a couple of the purple Indigo2 IMPACT systems, and an O2.....)
If you're thinking MIPS64, well, you can find that in embedded devices, routers, etc. Look for Cavium Octeon processors.
See https://en.wikipedia.org/wiki/List_of_MIPS_microprocessor_cores for which silicon is MIPS64.....
Red Hat Enterprise Linx 5 is still available and supported for IA64. At least at the moment; this will give IA64 users a Linux soure base at least until 2017.
I have personally rebuilt CentOS 5 from source for SGI Altix, which is an IA64 box, and am running a smallish Altix (30 CPU's, 54GB of RAM) in production for data analysis. (NASA's Columbia supercomputer was an IA64 Altix with 10,240 CPU's.....)
But RHEL 6 is indeed not available for IA64.
[I know I'm a day late....]
Harrison Mixbus. Commercial Ardour-derivative with fantastic sound, put out by Harrison Consoles, manufacturer of seriously high-end hardware. See http://www.harrisonconsoles.com/mixbus/website/ for its website. Runs natively on Windows, Max OS X, and Linux, and pretty much equally well on all three (runs best, IMO, on Linux, but I use it most on OS X due to some plugins I like).
...compared to free,
Today's caviat is that I admit not knowing how much OS X 10.8 cost off the shelf.
I paid $19.99 for both Lion and Mountain Lion, straight from the App Store (need to be at 10.6.8 first). Snow Leopard was a bit more expensive; I think it might have been $29.99 for the DVD. Leopard and prior were (and are, on eBay at least) quite a bit more than that.
Not anymore. Snow Leopard was the last version which came on physical media.
Lion was available on a USB stick. Search for it on eBay; still some sellers selling it (607-9072; found three on eBay just now for $55.95).
You have a point, but you lost credibility when you included OTA in that list. OTA is uncompressed 18.2mbit MPEG.
You lost credibility when you called MPEG 18.2Mb/s 'uncompressed.'
True uncompressed 1080p 24-bit color video requires a bit over 1.4Gb/s of bandwidth (do the math: 1920x1080 pixels; 24 bits per pixel; 30 frames per second = 1,492,992,000 bits per second.
18.2Mb/s is 82:1 compression. The discrete cosine transform is good, but not good enough to yield lossless compression of the video if you're constrained to a fixed bitrate. Especially in poor signal areas. And the typical 'HD' OTA station will only use 7Mb/s for their 'HD' output.
Uncompressed 720p video fares a bit better, only requiring 1366x720x24x30 = 708,134,400 bits per secons (around 700Mb/s), and so that typical 7Mb/s HD stream is actually 100:1 compressed (it's near lossless, and with static, blocky, content it can be completely lossless, but rapid motion means lost bits and a lossy section of the compression for a fixed bitrate. And so you see artifacts; grass, with its texture, is a near worst-case scenario for the DCT-based codecs, and so artifacting on grass is most definitely worse.
The 2008 revision of ATSC includes H.264 as a codec; I can 'see' H.264, and, like the GP, it does bother me.