An MS in Computer Science is theoretical for good reason: no amount of teaching will give you years of experience and the wisdom that comes with it. The MS complements the experience. Many companies recruit at grad schools and are eager to take on MS graduates regardless of their experience.
An IT degree makes sense at the Bachelor's level, because many employers have that as a minimum requirement and many people aren't really into the theoretical side of Computer Science, but beyond that you're probably better off getting RHCE, CCNA, or even MSCE if you want to do IT work.
Why would Microsoft care? They certain don't want to get into the hardware business. Intel is already in the software business, which is why this might make sense for them.
When I was at Red Hat, I assumed the scenario would be that Oracle would make a hostile takeover bid, as they are wont to do, and then IBM would come to the rescue with a competing offer that wouldn't gut the soul of the company quite as badly. Now that IBM is in talks with Sun, that seems less likely, unless the IBM/Sun deal falls through, in which case it's a no-brainer for IBM.
Failing that, the next best candidate, in terms of the good of the community, would be Intel. I mean no disrespect to AMD in this regard, because it's not really about hardware, but rather Intel's role as a technology mutual fund that happens to have CPU, chipset, and networking hardware in its portfolio. Adding a Linux vendor would further establish them as a developer of core computing technologies, in a role as a partner rather than a competitor to Oracle and IBM. Intel has a long history of working well with the open source community, which has certainly played a role in their acquisition of some top Red Hat talent over the past few years.
With all due respect to the many dedicated Linux engineers at Oracle, I don't trust Larry Ellison as far as I can throw him. Nor do I trust the Red Hat shareholders, who are overwhelmingly financial institutions on the brink of bankruptcy, to take any sort of long term view when considering competing offers, which is why I would not be shocked to see them cash out to Oracle, even knowing full well how the company would be gutted, because they so desperately need the money right now just to stay solvent. I just hope that when Oracle makes the move, which seems all but certain if the IBM/Sun deal goes through, that there's someone else around with a genuine commitment to the community and deep enough pockets to make a cash offer, since a stock deal under terms typical for large acquisitions wouldn't give the institutional shareholders the liquidity they need.
I used to work for Red Hat in a group that was working heavily with AMQP, and also with customer workloads on competing messaging products. There's a *lot* of money in that market, and a lot of entrenched interests with large patent portfolios that aren't competing in other areas where Red Hat has defensive patents, so the same patents that have kept other Red Hat competitors at bay may not be effective in the realtime messaging realm. As Red Hat expands into new market niches, their patent portfolio will expand further, at least until the state of software patents is more firmly established in the wake of the Bilski case.
Red Hat is loaded heavily with true believers, and management isn't dumb enough to do what Novell did and alienate the developers. The freedom of open source software extends to the professional developers as well, since they can take their skills elsewhere with no loss of value. As long as Red Hat keeps growing, I'm not particularly worried about them abusing their patent portfolio or any other leverage they may have to impair competition in the market. Once they saturate the market and have to start fighting tooth and nail just to avoid shrinking, then we'll really see those ideals put to the test.
Developing on a conventional SSD with large user-visible erase blocks is PAINFUL. The small writes caused by creating temporary files in the build process absolutely destroy performance. There are ludicrously expensive enterprise products which work around this in software, but at the laptop/desktop scale, you want something that's self-contained. As far as I'm aware, Intel's X25 drives are the only ones actually on the market now that hide the erase blocks effectively at the firmware level. The MLC ones should be fine.
The HPC and gaming communities probably won't care much about this, aside from the tweakers who spend $500 to overclock a $200 CPU to perform like a $400 CPU. The vast majority of workloads spend very little time in the kernel. The glaring exception to this is the network stack, where you can have a lot of rather CPU-intensive packet-mangling, routing, firewalling, IPSEC tunneling, and header processing done entirely in kernelspace. Ever try saturating a 10 Gbit ethernet interface? If you don't do some careful tuning, it quickly becomes CPU-bound, and much of that tuning is application-specific, so it's not much help when the applications generating the traffic are running remotely and beyond your control. Now try saturating two of them. Or more. This is one of the reasons why most people don't use Linux for high-end routing, but if it were possible, a lot of people would be very thrilled to move from things like IOS to something where they can use less exotic management tools that don't require such expensive training and support, and where there's much less vendor lock-in.
Common sense suggests that when you can't even beat single mothers who can't afford lawyers, you should avoid getting personal when litigating against someone who has close ties to the most influential legal minds in the country.
Trying to intimidate legal scholars won't work, but they're desperate, and they've already tried everything higher up on the list. At this rate, by the end of the year they'll probably start randomly breaking into houses looking for evidence of copying.
When I was hired as part of a large expansion of a rapidly-growing group, we went through much of the typical corporate team-building stuff to get to know each other quickly, but we were also given personality tests, and we discussed the results and how they would affect our roles in the group. It didn't tell us anything we wouldn't have learned about each other in the first few months, but it certainly made that process much easier.
My last smartphone case had two SD sleeves built into the cover. I had one card with music on it, and another I used for photos and file transfer. I never had a need for a third card to use both sleeves. My new phone uses microSDHC, so I got an 8 GB card (dirt cheap, even high speed) and never need to swap anything.
I really have a hard time seeing a need for more than one additional card that doesn't live in the device, unless you're doing something that would justify a filing system anyway.
Prior to the advent of skip protection in portable CD players, you could make them skip for several seconds just by shouting at them briefly, because it took much longer to recover from the vibration than the duration of the shock itself.
ZFS implements software RAID on top of JBOD. The box full of disks itself need not have any RAID controller, and if you're using RAID-Z, it would probably be a waste of money to spring for one, unless you go for the super-high-end for performance reasons.
After several bad experiences, even with UPSs, I have adopted the superstition of avoiding power supplies made by companies with "spark" in their names. Since this decision several years ago, the worst failure I've suffered is a drive that spewed SMART warnings for months -- but kept working -- until I finally RMAd it.
There's a very simple solution for the memory and interconnect bandwidth bottlenecks, and that is to widen the channels. If you look at Intel's Nehalem roadmap, they're planning to move from triple-channel to quad-channel on the really monstrous chips coming out down the line. Likewise, AMD has been doing a lot of work on making hypertransport channels more configurable, so you could allocate less bandwidth to an I/O bridge and more to the interconnect, if you're building a system where that's what's important.
If you're just adding more execution cores without changing what's around them, then this criticism hold, but the long-term significance of multi-core design is about VLSI, which lowers the latency between components. Latency is critical in supercomputing applications, so any time you can squeeze those gigaflops and their attached memory closer together, performance improves.
...that you should get a lawyer. That said, if your staff is small, the time to market exceeds the duration of the non-compete, and you make everyone sign an NDA, then by the time anyone knows you're competing, there will probably be very little they can do about it.
I seriously hope nobody is shipping RPMs with more than 2 GB of executable code, but many applications ship with gigabytes worth of templates, samples, artwork, models, benchmark data sets, maps, etc. Even if you break the contents of an installation DVD into functionally distinct subpackages, you can easily end up with a dozen libraries that are a few hundred KB, a few distinct applications that are tens of megabytes each, and few GB of application data that can't logically be split any further.
The really cool thing is the hardware support for masking CPUID calls from guests, so you don't have to emulate them in the hypervisor, which the VMware people in this thread have pointed out adds measurable overhead on some workloads. This lets you present a generic x86_64 CPU to the guest, which will run most non-HPC enterprise apps just fine. SSE2 is a mandatory part of the x86_64 instruction set, so all x86_64 processors will be able to get decently optimized math that can be live-migrated between different sub-architectures and processor revisions. You incur a slight performance hit on the older hosts, but this feature makes it easier to migrate away from them, which makes migrating to the new AMD processors much more attractive to people with large virt farms.
Rebooting isn't always an option. If you've got 10 guests running on a host, and you have the luxury of rebooting 9 of them, you still need to migrate one of them. Sure, you can keep separate pools of hosts with different processor revisions and migrate between them most of the time, but what happens when it's time to retire your rack full of netburst-era Xeon boxes, running several hundred guests? You're correct that CPUID trapping introduces overhead on older CPUs, but this demo was run on new CPUs, in part to show off how they make it easier to migrate to.
TSC timekeeping is essential for SMP scalability. When your hypervisor only supports 4-cpu scalability, you may not notice this effect, but for those of us running on bare metal or other hypervisors that allow us to use more CPUs, the effect becomes quite pronounced when running enterprise transactional workloads. The Linux kernel has gone to great lengths to use the most efficient timekeeping mechanism that can be used safely. The only patches I've seen lately on this topic have been to *enable* TSC timekeeping when running under VMware, since Linux distrusts the TSC by default, and has trouble verifying it in a virtualized environment.
When, in the history of charitable giving, has accepting a donation constituted an endorsement of the donor? They just don't want to have any perceived associated with D&D, at all, which is particularly vile for an organization that claims to be:
a) Christian b) a Children's fund
This isn't about Christians being pariahs, it's about gamers being pariahs, and adding that statement to the very brief story summary would have in no way changed this fact.
You're probably right, but the potential criminality is a key detail if you want to keep your job. Even in most at-will employment situations, while they can fire you for refusing to do something distasteful, they can't legally fire you for refusing to commit a crime. If they do fire you, you get to sue them, which they know is very expensive, so hopefully they'll be smart enough not to try. Of course, this varies by jurisdiction and IANAL.
Slashdot Mirror
An MS in Computer Science is theoretical for good reason: no amount of teaching will give you years of experience and the wisdom that comes with it. The MS complements the experience. Many companies recruit at grad schools and are eager to take on MS graduates regardless of their experience.
An IT degree makes sense at the Bachelor's level, because many employers have that as a minimum requirement and many people aren't really into the theoretical side of Computer Science, but beyond that you're probably better off getting RHCE, CCNA, or even MSCE if you want to do IT work.
Why would Microsoft care? They certain don't want to get into the hardware business. Intel is already in the software business, which is why this might make sense for them.
When I was at Red Hat, I assumed the scenario would be that Oracle would make a hostile takeover bid, as they are wont to do, and then IBM would come to the rescue with a competing offer that wouldn't gut the soul of the company quite as badly. Now that IBM is in talks with Sun, that seems less likely, unless the IBM/Sun deal falls through, in which case it's a no-brainer for IBM.
Failing that, the next best candidate, in terms of the good of the community, would be Intel. I mean no disrespect to AMD in this regard, because it's not really about hardware, but rather Intel's role as a technology mutual fund that happens to have CPU, chipset, and networking hardware in its portfolio. Adding a Linux vendor would further establish them as a developer of core computing technologies, in a role as a partner rather than a competitor to Oracle and IBM. Intel has a long history of working well with the open source community, which has certainly played a role in their acquisition of some top Red Hat talent over the past few years.
With all due respect to the many dedicated Linux engineers at Oracle, I don't trust Larry Ellison as far as I can throw him. Nor do I trust the Red Hat shareholders, who are overwhelmingly financial institutions on the brink of bankruptcy, to take any sort of long term view when considering competing offers, which is why I would not be shocked to see them cash out to Oracle, even knowing full well how the company would be gutted, because they so desperately need the money right now just to stay solvent. I just hope that when Oracle makes the move, which seems all but certain if the IBM/Sun deal goes through, that there's someone else around with a genuine commitment to the community and deep enough pockets to make a cash offer, since a stock deal under terms typical for large acquisitions wouldn't give the institutional shareholders the liquidity they need.
I used to work for Red Hat in a group that was working heavily with AMQP, and also with customer workloads on competing messaging products. There's a *lot* of money in that market, and a lot of entrenched interests with large patent portfolios that aren't competing in other areas where Red Hat has defensive patents, so the same patents that have kept other Red Hat competitors at bay may not be effective in the realtime messaging realm. As Red Hat expands into new market niches, their patent portfolio will expand further, at least until the state of software patents is more firmly established in the wake of the Bilski case.
Red Hat is loaded heavily with true believers, and management isn't dumb enough to do what Novell did and alienate the developers. The freedom of open source software extends to the professional developers as well, since they can take their skills elsewhere with no loss of value. As long as Red Hat keeps growing, I'm not particularly worried about them abusing their patent portfolio or any other leverage they may have to impair competition in the market. Once they saturate the market and have to start fighting tooth and nail just to avoid shrinking, then we'll really see those ideals put to the test.
Developing on a conventional SSD with large user-visible erase blocks is PAINFUL. The small writes caused by creating temporary files in the build process absolutely destroy performance. There are ludicrously expensive enterprise products which work around this in software, but at the laptop/desktop scale, you want something that's self-contained. As far as I'm aware, Intel's X25 drives are the only ones actually on the market now that hide the erase blocks effectively at the firmware level. The MLC ones should be fine.
The HPC and gaming communities probably won't care much about this, aside from the tweakers who spend $500 to overclock a $200 CPU to perform like a $400 CPU. The vast majority of workloads spend very little time in the kernel. The glaring exception to this is the network stack, where you can have a lot of rather CPU-intensive packet-mangling, routing, firewalling, IPSEC tunneling, and header processing done entirely in kernelspace. Ever try saturating a 10 Gbit ethernet interface? If you don't do some careful tuning, it quickly becomes CPU-bound, and much of that tuning is application-specific, so it's not much help when the applications generating the traffic are running remotely and beyond your control. Now try saturating two of them. Or more. This is one of the reasons why most people don't use Linux for high-end routing, but if it were possible, a lot of people would be very thrilled to move from things like IOS to something where they can use less exotic management tools that don't require such expensive training and support, and where there's much less vendor lock-in.
I believe you mis-spelled "equity".
North Korea won't even have tin cans and string everywhere by 2012.
Common sense suggests that when you can't even beat single mothers who can't afford lawyers, you should avoid getting personal when litigating against someone who has close ties to the most influential legal minds in the country.
Trying to intimidate legal scholars won't work, but they're desperate, and they've already tried everything higher up on the list. At this rate, by the end of the year they'll probably start randomly breaking into houses looking for evidence of copying.
When I was hired as part of a large expansion of a rapidly-growing group, we went through much of the typical corporate team-building stuff to get to know each other quickly, but we were also given personality tests, and we discussed the results and how they would affect our roles in the group. It didn't tell us anything we wouldn't have learned about each other in the first few months, but it certainly made that process much easier.
My last smartphone case had two SD sleeves built into the cover. I had one card with music on it, and another I used for photos and file transfer. I never had a need for a third card to use both sleeves. My new phone uses microSDHC, so I got an 8 GB card (dirt cheap, even high speed) and never need to swap anything.
I really have a hard time seeing a need for more than one additional card that doesn't live in the device, unless you're doing something that would justify a filing system anyway.
Prior to the advent of skip protection in portable CD players, you could make them skip for several seconds just by shouting at them briefly, because it took much longer to recover from the vibration than the duration of the shock itself.
ZFS implements software RAID on top of JBOD. The box full of disks itself need not have any RAID controller, and if you're using RAID-Z, it would probably be a waste of money to spring for one, unless you go for the super-high-end for performance reasons.
After several bad experiences, even with UPSs, I have adopted the superstition of avoiding power supplies made by companies with "spark" in their names. Since this decision several years ago, the worst failure I've suffered is a drive that spewed SMART warnings for months -- but kept working -- until I finally RMAd it.
There's a very simple solution for the memory and interconnect bandwidth bottlenecks, and that is to widen the channels. If you look at Intel's Nehalem roadmap, they're planning to move from triple-channel to quad-channel on the really monstrous chips coming out down the line. Likewise, AMD has been doing a lot of work on making hypertransport channels more configurable, so you could allocate less bandwidth to an I/O bridge and more to the interconnect, if you're building a system where that's what's important.
If you're just adding more execution cores without changing what's around them, then this criticism hold, but the long-term significance of multi-core design is about VLSI, which lowers the latency between components. Latency is critical in supercomputing applications, so any time you can squeeze those gigaflops and their attached memory closer together, performance improves.
...that you should get a lawyer. That said, if your staff is small, the time to market exceeds the duration of the non-compete, and you make everyone sign an NDA, then by the time anyone knows you're competing, there will probably be very little they can do about it.
I seriously hope nobody is shipping RPMs with more than 2 GB of executable code, but many applications ship with gigabytes worth of templates, samples, artwork, models, benchmark data sets, maps, etc. Even if you break the contents of an installation DVD into functionally distinct subpackages, you can easily end up with a dozen libraries that are a few hundred KB, a few distinct applications that are tens of megabytes each, and few GB of application data that can't logically be split any further.
Half the bugs will sit in NEW status until the shuttle is retired, then they'll be closed WONTFIX.
If you don't want publicity associating you with the Stasi, this probably isn't the best method of challenging the accusation.
Any list of bests that includes any mention of The Core automatically loses all credibility.
http://www.gsa.gov/Portal/gsa/ep/contentView.do?programId=8951&channelId=-14501&ooid=18177&contentId=12854&pageTypeId=8199&contentType=GSA_BASIC&programPage=%2Fep%2Fprogram%2FgsaBasic.jsp&P=XAE
At the cabinet level, we need a visionary.
The really cool thing is the hardware support for masking CPUID calls from guests, so you don't have to emulate them in the hypervisor, which the VMware people in this thread have pointed out adds measurable overhead on some workloads. This lets you present a generic x86_64 CPU to the guest, which will run most non-HPC enterprise apps just fine. SSE2 is a mandatory part of the x86_64 instruction set, so all x86_64 processors will be able to get decently optimized math that can be live-migrated between different sub-architectures and processor revisions. You incur a slight performance hit on the older hosts, but this feature makes it easier to migrate away from them, which makes migrating to the new AMD processors much more attractive to people with large virt farms.
Rebooting isn't always an option. If you've got 10 guests running on a host, and you have the luxury of rebooting 9 of them, you still need to migrate one of them. Sure, you can keep separate pools of hosts with different processor revisions and migrate between them most of the time, but what happens when it's time to retire your rack full of netburst-era Xeon boxes, running several hundred guests? You're correct that CPUID trapping introduces overhead on older CPUs, but this demo was run on new CPUs, in part to show off how they make it easier to migrate to.
TSC timekeeping is essential for SMP scalability. When your hypervisor only supports 4-cpu scalability, you may not notice this effect, but for those of us running on bare metal or other hypervisors that allow us to use more CPUs, the effect becomes quite pronounced when running enterprise transactional workloads. The Linux kernel has gone to great lengths to use the most efficient timekeeping mechanism that can be used safely. The only patches I've seen lately on this topic have been to *enable* TSC timekeeping when running under VMware, since Linux distrusts the TSC by default, and has trouble verifying it in a virtualized environment.
When, in the history of charitable giving, has accepting a donation constituted an endorsement of the donor? They just don't want to have any perceived associated with D&D, at all, which is particularly vile for an organization that claims to be:
a) Christian
b) a Children's fund
This isn't about Christians being pariahs, it's about gamers being pariahs, and adding that statement to the very brief story summary would have in no way changed this fact.
You're probably right, but the potential criminality is a key detail if you want to keep your job. Even in most at-will employment situations, while they can fire you for refusing to do something distasteful, they can't legally fire you for refusing to commit a crime. If they do fire you, you get to sue them, which they know is very expensive, so hopefully they'll be smart enough not to try. Of course, this varies by jurisdiction and IANAL.