There is only 446 bytes available in the MBR. That's insufficient for code that can read a filesystem to find the 2nd stage image. When we go to 4096 byte sectors, there might be.
A 512 byte sector (MBR) does not have enough space for code to read a filesystem. So either you waste a whole partition just for the next bootloader stage... which in the days of MBR partitions, there were not enough available to do that... or you just sequence the sectors after the MBR, which then gives enough space to load minimal filesystem read-only support. LILO can play tricks to fake raw sectors inside a filesystem, but that is a very fragile setup that breaks whenever the filesystem is changed.
It has been quite normal for decades to have boot loader code in the sectors right after the MBR. It has never been normal for any other code to put anything here.
With the new GUID Partition Table (GPT) format, there are 128 partitions available. That's enough to use one or two for boot loader extra code. Any demands for bootloaders to put their next stage code inside a partition should be paired with the demand to use GPT, too.
Maybe we're thinking entirely about different kinds of work loads. Maybe VMs are good for a lot of distinctively different types of workloads which would need migrating when idle or lightly loaded. I'm looking at identical class workloads on a large array of machines, any of which could do each job just fine. No migration is needed. When the overall workload is light, just shutdown and power off the machines that are idle. When the work scheduler detects more machines need to be up, it commands the PDUs to power enough of them back on. I see no need for VMs on these.
I remember one job I interviewed for. They wanted one particular skill I didn't have. I told them I could learn it and be fully productive in 4 to 6 weeks, using all my other skills as a foundation. They declined to offer me the job, saying they really needed to have someone who could hit the ground running. Six months later, they will still looking for that talent.
Unfortunately, in larger companies (and yes, there are people that are happy to work for larger companies), corporate policies get in the way and require HR to do the filtering. Then the IT manager has to choose between using relevant topics that HR is likely to screw up, or use irrelevant topics that will just lead HR to pick at random because everyone matched. Or worse, pick the people that state the lowest required salary (which, BTW, I never put on a resume).
The rockstar programmer is not dead. They are just working for someone else right now. The conventional job hunt is not the way to find them, for the most part. When they do lose a job (because the company's financial people fail, for example), they usually have contacts in place and can latch a new job quickly. Those that don't have such contacts might build them online. Open source projects are one of the places (though RethinkDB might be working way to narrow with just a couple places). Hopefully, they will be approaching this less as a quick-hire place, and more as a build-contact place. They might well find the rockstar there today, that they can hire two years from now.
But I can understand the want to hire the top-talented core people, often just two or three of them, who will then be surrounded by a team of twenty to forty eager beaver programmers who can at least understand new concepts, even if they are not seasoned enough to create them on their own. It seems to me RethinkDB is trying to do this, but doesn't realize it actually is very hard to do.
California itself is problematic. It's perceived as the go-to place for tech jobs. So everyone that wants one goes there. That's why it has both a surplus and a shortage at the same time. It's being diluted by the lower 50%. Once they can spread out and hire people from other locations, they'll find out where those lower-end programmers moved away from. Top-level talent doesn't need to move and it will exist in its small proportion everywhere.
FYI, I've turned down a job at more than double the pay these guys are offering, just because it was in California. I would have taken it if I could have telecommuted and visited in person three or four times a year for a week each. If they were hiring within 100km of me, or in any of the places I'd be happy to move to, then I'd send them a resume and see if they will still look at those.
If no one can solve that simple C problem they posted, then I can understand their concern about the lack of good programmers. I looked at their job posting and it isn't a long grocery list. It still might be shortened, but it's nowhere near the typical I have seen from larger companies which overly formalize the process with clueless HR people. Relatively speaking, this company is a breath of fresh air, even if their level is set a bit high. One thing they should learn is that building a top-level team isn't done fast. The very best talent is often in contact for years before they make the jump.
So do you think you didn't get the job because their requirements are too narrow? What didn't you fit? I wonder if you would fit in where I work (we just signed for more funding, and will be hiring more soon, maybe before the end of the year).
Actually, they do seem to be able to recognize when people are not the right fit during that four hour interview. Their whole story is that they are finding that everyone they do interview that way are people they don't want to hire. The problem is, this is inefficient considering the glut of programmers below the level they want. The article is about finding alternatives to this process where this glut can be avoided. Maybe better phone screen skills might have done so? But they seem to think there is success in going to the source, where the good programmers are known to hang out. Of course, the big problem there is most of them don't want a new job.
The US government is getting some info from RIM, but it does not include getting copies of email. BB is popular among foreigners coming to India to do business. If RIM is cut off, this will hurt India's ability to do business with the rest of the world that doesn't have this approach to government.
Another point that needs to be made is that foreign businesses doing business in India with Indian businesses will be at greater risk, and that can hurt the business. Sure, things are done different in India. They are different elsewhere when compared to India, too. It's the international business where one party is in India that will suffer. And there is also the perception that the corruption involved puts that very data they capture at risk, potentially leaking it to competitors for more of those handouts.
... then lots of businesses outside of India will need to stop doing business with businesses located in India. It can hurt Indian business by doing this.
I think his point is that by only applying the deep inspection on traffic to/from a specific IP address, by means of techniques like source routing (Cisco routers can do this... BTDT), the deep packet inspection isn't so much of an added cost. OTOH, sites like facebook.com and still need a lot of deep inspection threads and capacity. Still, it would not impact other traffic so much.
It could also be a time dilation effect, where the atomic decay is affected by time dilation differently than other things are affected. Just another WAG.
... if there can be a 9or many) fully legal (to use and to redistribute) open source (BSD or GPL class licensing) implementation(s) to view videos in this format, so they can be used in <video> tags, and viewed in other means. Oh, and for encoding, too.
It would have made more sense to power it at 240 volts. It would have been in balance at any number of loads, and actually reduced the current somewhat as most PSUs run more efficiently at 240 volts than at 120 volts.
Not all buildings get all voltages. Typically a building gets a single "service voltage", which could be (in the USA) 120/240 volts for single phase, 120/208 volts for three phase, or 120/240 volt three phase using a depricated delta wired transformer bank, or 277/480 volt three phase. Canada has a lot of 347/600 volt three phase around (and also a few places in the USA). And in a few places you can get 138.5/240 or 240/416 in three phase. In many places, street lights run on 480 volt single phase or three phase. It is rare for a building to get more that one of these. They have to use their own transformers to convert otherwise.
The best choice for a very large data center where almost everything is computers is 240/416. Then just run everything at 240 volts. Less current and less I2R power loss.
Slashdot Mirror
There is only 446 bytes available in the MBR. That's insufficient for code that can read a filesystem to find the 2nd stage image. When we go to 4096 byte sectors, there might be.
A 512 byte sector (MBR) does not have enough space for code to read a filesystem. So either you waste a whole partition just for the next bootloader stage ... which in the days of MBR partitions, there were not enough available to do that ... or you just sequence the sectors after the MBR, which then gives enough space to load minimal filesystem read-only support. LILO can play tricks to fake raw sectors inside a filesystem, but that is a very fragile setup that breaks whenever the filesystem is changed.
It has been quite normal for decades to have boot loader code in the sectors right after the MBR. It has never been normal for any other code to put anything here.
With the new GUID Partition Table (GPT) format, there are 128 partitions available. That's enough to use one or two for boot loader extra code. Any demands for bootloaders to put their next stage code inside a partition should be paired with the demand to use GPT, too.
That's an old COLOR TV (Sony Trinitron) being fed with a black and white image.
Yeah, I noticed their salary levels are more in line with Pittsburgh.
Maybe we're thinking entirely about different kinds of work loads. Maybe VMs are good for a lot of distinctively different types of workloads which would need migrating when idle or lightly loaded. I'm looking at identical class workloads on a large array of machines, any of which could do each job just fine. No migration is needed. When the overall workload is light, just shutdown and power off the machines that are idle. When the work scheduler detects more machines need to be up, it commands the PDUs to power enough of them back on. I see no need for VMs on these.
What if you don't want to go to the Bay area, or anywhere in California?
And what's wrong with rsync for backups?
I remember one job I interviewed for. They wanted one particular skill I didn't have. I told them I could learn it and be fully productive in 4 to 6 weeks, using all my other skills as a foundation. They declined to offer me the job, saying they really needed to have someone who could hit the ground running. Six months later, they will still looking for that talent.
Unfortunately, in larger companies (and yes, there are people that are happy to work for larger companies), corporate policies get in the way and require HR to do the filtering. Then the IT manager has to choose between using relevant topics that HR is likely to screw up, or use irrelevant topics that will just lead HR to pick at random because everyone matched. Or worse, pick the people that state the lowest required salary (which, BTW, I never put on a resume).
The rockstar programmer is not dead. They are just working for someone else right now. The conventional job hunt is not the way to find them, for the most part. When they do lose a job (because the company's financial people fail, for example), they usually have contacts in place and can latch a new job quickly. Those that don't have such contacts might build them online. Open source projects are one of the places (though RethinkDB might be working way to narrow with just a couple places). Hopefully, they will be approaching this less as a quick-hire place, and more as a build-contact place. They might well find the rockstar there today, that they can hire two years from now.
But I can understand the want to hire the top-talented core people, often just two or three of them, who will then be surrounded by a team of twenty to forty eager beaver programmers who can at least understand new concepts, even if they are not seasoned enough to create them on their own. It seems to me RethinkDB is trying to do this, but doesn't realize it actually is very hard to do.
California itself is problematic. It's perceived as the go-to place for tech jobs. So everyone that wants one goes there. That's why it has both a surplus and a shortage at the same time. It's being diluted by the lower 50%. Once they can spread out and hire people from other locations, they'll find out where those lower-end programmers moved away from. Top-level talent doesn't need to move and it will exist in its small proportion everywhere.
FYI, I've turned down a job at more than double the pay these guys are offering, just because it was in California. I would have taken it if I could have telecommuted and visited in person three or four times a year for a week each. If they were hiring within 100km of me, or in any of the places I'd be happy to move to, then I'd send them a resume and see if they will still look at those.
If no one can solve that simple C problem they posted, then I can understand their concern about the lack of good programmers. I looked at their job posting and it isn't a long grocery list. It still might be shortened, but it's nowhere near the typical I have seen from larger companies which overly formalize the process with clueless HR people. Relatively speaking, this company is a breath of fresh air, even if their level is set a bit high. One thing they should learn is that building a top-level team isn't done fast. The very best talent is often in contact for years before they make the jump.
So do you think you didn't get the job because their requirements are too narrow? What didn't you fit? I wonder if you would fit in where I work (we just signed for more funding, and will be hiring more soon, maybe before the end of the year).
Actually, they do seem to be able to recognize when people are not the right fit during that four hour interview. Their whole story is that they are finding that everyone they do interview that way are people they don't want to hire. The problem is, this is inefficient considering the glut of programmers below the level they want. The article is about finding alternatives to this process where this glut can be avoided. Maybe better phone screen skills might have done so? But they seem to think there is success in going to the source, where the good programmers are known to hang out. Of course, the big problem there is most of them don't want a new job.
... unless you want to find programmers.
That's one way to do it. It's not the only way. Expect terrorists to be running their own encrypted servers somewhere soon, if not already.
Does it use IMAPS?
Put the servers in Sweden.
The US government is getting some info from RIM, but it does not include getting copies of email. BB is popular among foreigners coming to India to do business. If RIM is cut off, this will hurt India's ability to do business with the rest of the world that doesn't have this approach to government.
Another point that needs to be made is that foreign businesses doing business in India with Indian businesses will be at greater risk, and that can hurt the business. Sure, things are done different in India. They are different elsewhere when compared to India, too. It's the international business where one party is in India that will suffer. And there is also the perception that the corruption involved puts that very data they capture at risk, potentially leaking it to competitors for more of those handouts.
... then lots of businesses outside of India will need to stop doing business with businesses located in India. It can hurt Indian business by doing this.
I think his point is that by only applying the deep inspection on traffic to/from a specific IP address, by means of techniques like source routing (Cisco routers can do this ... BTDT), the deep packet inspection isn't so much of an added cost. OTOH, sites like facebook.com and still need a lot of deep inspection threads and capacity. Still, it would not impact other traffic so much.
It could also be a time dilation effect, where the atomic decay is affected by time dilation differently than other things are affected. Just another WAG.
You don't need VMware to do that.
At 240 volts it would always be balanced no matter what combination of loads would be used. And it would more likely be 12 amps instead of 13.
... if there can be a 9or many) fully legal (to use and to redistribute) open source (BSD or GPL class licensing) implementation(s) to view videos in this format, so they can be used in <video> tags, and viewed in other means. Oh, and for encoding, too.
It would have made more sense to power it at 240 volts. It would have been in balance at any number of loads, and actually reduced the current somewhat as most PSUs run more efficiently at 240 volts than at 120 volts.
Not all buildings get all voltages. Typically a building gets a single "service voltage", which could be (in the USA) 120/240 volts for single phase, 120/208 volts for three phase, or 120/240 volt three phase using a depricated delta wired transformer bank, or 277/480 volt three phase. Canada has a lot of 347/600 volt three phase around (and also a few places in the USA). And in a few places you can get 138.5/240 or 240/416 in three phase. In many places, street lights run on 480 volt single phase or three phase. It is rare for a building to get more that one of these. They have to use their own transformers to convert otherwise.
The best choice for a very large data center where almost everything is computers is 240/416. Then just run everything at 240 volts. Less current and less I2R power loss.