When was this? Before mortgages, most people either inherited their parents house when they died (and maybe sold it and bought a different one), were already rich and owned multiple houses, renting most of them, or rented their entire lives. In the USA, poor people didn't buy houses, they either rented or they found a bit of land that no one was using, claimed it, and built a shack on it, gradually improving it until it was more of a house than a shack.
That's pretty much the same everywhere. Having no credit history means that you have never borrowed money (as far as they can tell). This doesn't make you a safe bet, this makes you completely unknown. Good credit history means that you have borrowed and paid back money in the past. It means that, judging by past behaviour, any loan that you take out will be paid back.
When you borrow money, you have to budget for the interest and the final repayment. If you've never borrowed money before, then there is no evidence that you can do this - you might have been living hand-to-mouth up until then. Lenders would rather let you borrow a small amount, see that you can pay it back, let you borrow a bit more, and so on.
Actually, the final repayment isn't that important. If you have a long-term loan and are making all of the interest payments. Interest payments are regular income, and a bank is generally happy to keep extending the duration of a loan as long as you keep up the interest - if you pay it back, they'll just try to loan the money to someone else.
Barclays were the ONLY BANK THAT WOULD CONSIDER ME FOR A PERSONAL ACCOUNT
Your story is full of WTFs, but this one seems like one of the most strange. Are you certified mentally ill or a discharged bankrupt? These are the only two reasons I've heard of any of the high-street banks refusing someone a current account, and neither of them makes you the kind of person I'd listen to for financial advice.
Just make sure that the bank (BoA in your case) doesn't charge you fees for low balances
WTF? A fee for low balances? I thought the US banking system was a bit fucked up with charges for EFT and for using cash machines, but a charge for not keeping enough money in your bank account?!?! The worst that they'll do on this side of the pond is have a lower interest rate if you're below a certain threshold.
Seeing as speed (on 15+ year old equipment) was the reason they did it, you're not going to get an answer you like.
Sorry, but that reason is bullshit. Rendering fonts is performance-critical. Parsing the fonts is not. The vulnerability is in the code responsible for turning a font file into a set of bezier paths that the display subsystem can render. This code is not performance critical, nor does it need to run with any privileges other than the ability to read the font file (or read font data from a pipe or memory buffer) and write the bezier paths somewhere.
Moving the code that takes the output from this bit of code into the kernel makes sense, because that really is performance critical. Rendering text is one of the most CPU-intensive things a modern windowing system does. Parsing font files is not.
The sane way of doing this would be to have a font service that would run as an unprivileged user, parse TrueType fonts and pass the beziers to the graphics subsystem in the kernel. This was possible with the NT security model from the start. This wouldn't even have cost anything in terms of performance - parsing the font file is not performance-critical, only rendering the resulting glyphs is.
There was a time when the X11 server parsed fonts directly, and it was running as root, perhaps with some privileges dropped along the way
Kind of. It did, but only of fonts installed on the X server. This meant that it was not parsing untrusted font data. This approach was problematic, because it meant that if you installed an office suite on a server then you needed to install all of its fonts on every thin client machine, or it needed to do all of the font rendering and then just send images to the X servers. Modern (i.e. for about the last decade) X systems have done font parsing and rendering on the client but stored the rendered glyphs on the server, where they can be composited quickly. This also has the advantage that the same rendering code can be used for any font format without the display server needing to know how it works.
I visit Google periodically, and every time I find myself less impressed with the people I meet. I don't know whether this means that I've become immune to the Google mystique, if my standards have gone up, or if they've been lowering their recruiting standards. I do know that the friends of mine who went to work there a few years ago and told me how great a place it was to work and how they were surrounded by smart people and doing interesting and creative stuff are now telling me about bullshit processes, idiot managers, and the places they're thinking of moving to when they quit Google.
I really want to believe that you are exaggerating. Last time I wrote code like that I was 14 (in OPL for the Psion Series 3 originally, then again in C). I've not done any graphics stuff (except for mentoring a summer of code student who was working on some graphics API things) since I finished my PhD, and as little as I could get away with back then, and it still sounds like a trivial problem. I guess it depends on the APIs - presumably they had some kind of set pixel or draw line function (or a frame buffer in memory) available and it wasn't some weird system?
Do Google and Facebook have that many applicants? Their recruiters keep pestering me, and the Facebook one seemed quite disturbingly desperate. Neither seemed like they were swamped with candidates. If you have thousands of qualified candidates for every position, then you don't generally approach more unsolicited...
I had a really good telephone interview for one company. The initial question was impossible, and a few seconds thought made me realise it was impossible. Part of the point was to see how you approach this kind of challenge, when confronted with really bad specifications. The problem - as stated - was impossible, but it was possible to solve it in the cases where people were actually likely to care about the results. I quickly came up with a hacky solution with the proviso that it would be inefficient but may not be worth optimising depending on how it was being used. He then asked me how it could be optimised, and we discussed a few strategies. Most of the half hour interview was focussed on the same problem, but the requirements gradually changed and by the end it was focussing entirely on speed and not caring about 100% accuracy for the algorithm as long as the common cases were very fast.
And, more importantly, remembering printf tells you nothing about the candidate. I could have remembered any of the things the grandparent suggests when I was 11. I can still remember them now. Hiring someone with 11-year-old me's knowledge of C would be a disaster for most companies (I'd like to think hiring me now would be a bit better). This kind of test checks for superficial understanding of the language, but little more. If you're relying on the interview to test whether the applicant has read the first chapter of a C book, then you should reevaluate the rest of your hiring process...
Depends on the complexity of the problems. If they're very simple, any vaguely competent applicant will be able to solve them, but that won't tell you anything because you should have filtered out the ones who couldn't long before they got to the in-person interview. More complex ones will filter people out, but on a criteria that is so far divorced from any relevance to the job that you may as well ask them to paint a picture or compose a song.
And it makes about as much sense as asking an applicant for a job as a truck driver to run carrying a heavy backpack. Sure, the test and the job both involve moving heavy goods, but skill at one is not really related to skill at the other.
A good programmer types largely subconsciously. You think about the structure and your hindbrain makes your fingers translate it into concrete syntax. Move to a board, and now you're consciously thinking about the syntax, and probably consciously thinking about moving the pen, since writing on a board is not something most programmers do regularly.
Simon Crosby is not the creator of Xen. It was created by Keir Fraser while he was doing his PhD, under supervision by Ian Pratt (it was actually created as the result of a drunken bet between Keir and Ian). They then went on to found XenSource, which was bought by Citrix. Simon Crosby (yes, his name does have a y on the end - well edited Slashdot) was brought in to do marketing for XenSource. He had very little to do with the technical side.
On my laptop, Xen is a bit over 650KB, but the initrd image for my kernel is about 11MB.
Two things here. First, the initrd image is a RAM disk containing a recovery filesystem. If you want to compare it to Xen, you need to compare it to the Xen admin tools as well as the kernel - and they are written in Python so come with 5MB of Python dependencies before you even get them to start. Secondly, 90% of the size of any modern kernel is device drivers. Xen does not contain any device drivers - it delegates all of that to the domain 0 guest (or to multiple driver domains).
I'm actually quite surprised that Xen is 650KB. That seems a lot bigger than it should be for what it actually does: schedule VMs to run on the physical CPUs and allocate pages of physical memory to them.
Often, you'd get root on a server because one of the service that is running has flows. Not because of a kernel root exploits. In this case, having things isolated means you'd get root only on a server running a single service
This makes no sense. If you compromise, say, Apache, then you can control Apache, but nothing else. Apache runs in a chroot, so you can't even see the rest of the filesystem. You only get root if there is also a local privilege escalation vulnerability in the kernel, or if the user was stupid enough to run Apache as root (and if they're going to misconfigure services in an OS, what makes you think they won't misconfigure VMs?).
The difference is, mainframes did it properly. The first system to support virtualisation was VM/360. It didn't just support virtualisation, it supported recursive virtualisation. This meant that any VM could contain other VMs, so you could use the same abstraction for isolation at any level. Operating systems provide a very limited form of virtualisation: processes. A userspace process is basically a VM for a paravirtualised architecture. Any time it wants to talk to the hardware, it has to go via the kernel. The problem is, it stops there. A process can't contain other processes which can only contact the kernel via the parent process, so programs end up adding their own ad-hoc isolation mechanisms. Things like the JVM, web browsers, even office apps all need to run untrusted code but have to isolate it without any help from the hardware. Fortunately, modern systems are providing things like capsicum, sandbox, and systrace, so it is now possible to create a child process with very restricted privileges.
Not surprising. Simon Crosby was the CTO of XenSource before it was purchased. He was in charge of marketing. Kier Fraser and Ian Pratt were the two who were in charge on the technical side.
You seem to misunderstand what the sandbox is. OS X has had a set of APIs for sandboxing applications since 10.5. The sandbox(7) man page will tell you a lot about it. This comes with a few default policies, and you can add more. If you download an app and don't trust it, then you can start it in a sandbox (there's no GUI for doing this, which sucks, but it would be a few hours work to add one).
This isn't an 'authoritarian model' any more than the UNIX process model is: the kernel is the authority and any application has to go begging to it for access to anything. You can ship your own sandbox policies if you want to implement privilege separation and so on in your OS X application, and a lot of Apple's programs use it already, and have for a while - you may remember a mDNSResponder vulnerability that only affected 10.4, because it ran in a sandbox on 10.5. You can see the sandbox definition that mDNSResponder uses and it's pretty trivial to put something similar together for your own daemon.
The only difference now is that Apple is defining a sandbox profile for normal applications and forcing developers to use it if they want their application in the App Store. It is not a whitelist of applications, it's just a default security policy that applications must work with. This is like Microsoft requiring applications to work as non-Administrator users for the Designed For... certification, or a Linux distribution rejecting suid root apps from the default repository.
If the advice is 'don't be a troll' there isn't much harm. Either they'll ignore it or be unable to follow it, in which case it won't do any harm, or they will follow it and we're down one troll...
Linux is the most popular brand of POSIX, and mostly, vim is used on it.
I'd have thought OS X was a bit more popular than Linux (and a lot more POSIX compliant - it's actually certified as conforming to the Single UNIX Specification, while I regularly come across places where Linux makes a half-arsed stab at implementing the standard). It ships with vim, although the system vim never gets updated over the lifetime of an OS X release so it tends to be a bit out of date quickly.
I doubt it. I've not come across a system with vi installed as vi for years. BSDs ship with nvi, OS X and most Linux systems ship with vim, although a couple of Linux distributions use elvis. It was a derivative work of the original AT&T ed, which meant that it could only be used by people who had an AT&T UNIX license. It was only a few years ago that the ed code was open sourced and people could start shipping vi, but by this time vim, nvi, and elvis were pretty entrenched, and there wasn't much point in saving a hundred KB on disk.
Slashdot Mirror
When was this? Before mortgages, most people either inherited their parents house when they died (and maybe sold it and bought a different one), were already rich and owned multiple houses, renting most of them, or rented their entire lives. In the USA, poor people didn't buy houses, they either rented or they found a bit of land that no one was using, claimed it, and built a shack on it, gradually improving it until it was more of a house than a shack.
That's pretty much the same everywhere. Having no credit history means that you have never borrowed money (as far as they can tell). This doesn't make you a safe bet, this makes you completely unknown. Good credit history means that you have borrowed and paid back money in the past. It means that, judging by past behaviour, any loan that you take out will be paid back.
When you borrow money, you have to budget for the interest and the final repayment. If you've never borrowed money before, then there is no evidence that you can do this - you might have been living hand-to-mouth up until then. Lenders would rather let you borrow a small amount, see that you can pay it back, let you borrow a bit more, and so on.
Actually, the final repayment isn't that important. If you have a long-term loan and are making all of the interest payments. Interest payments are regular income, and a bank is generally happy to keep extending the duration of a loan as long as you keep up the interest - if you pay it back, they'll just try to loan the money to someone else.
Barclays were the ONLY BANK THAT WOULD CONSIDER ME FOR A PERSONAL ACCOUNT
Your story is full of WTFs, but this one seems like one of the most strange. Are you certified mentally ill or a discharged bankrupt? These are the only two reasons I've heard of any of the high-street banks refusing someone a current account, and neither of them makes you the kind of person I'd listen to for financial advice.
Just make sure that the bank (BoA in your case) doesn't charge you fees for low balances
WTF? A fee for low balances? I thought the US banking system was a bit fucked up with charges for EFT and for using cash machines, but a charge for not keeping enough money in your bank account?!?! The worst that they'll do on this side of the pond is have a lower interest rate if you're below a certain threshold.
Seeing as speed (on 15+ year old equipment) was the reason they did it, you're not going to get an answer you like.
Sorry, but that reason is bullshit. Rendering fonts is performance-critical. Parsing the fonts is not. The vulnerability is in the code responsible for turning a font file into a set of bezier paths that the display subsystem can render. This code is not performance critical, nor does it need to run with any privileges other than the ability to read the font file (or read font data from a pipe or memory buffer) and write the bezier paths somewhere.
Moving the code that takes the output from this bit of code into the kernel makes sense, because that really is performance critical. Rendering text is one of the most CPU-intensive things a modern windowing system does. Parsing font files is not.
The sane way of doing this would be to have a font service that would run as an unprivileged user, parse TrueType fonts and pass the beziers to the graphics subsystem in the kernel. This was possible with the NT security model from the start. This wouldn't even have cost anything in terms of performance - parsing the font file is not performance-critical, only rendering the resulting glyphs is.
There was a time when the X11 server parsed fonts directly, and it was running as root, perhaps with some privileges dropped along the way
Kind of. It did, but only of fonts installed on the X server. This meant that it was not parsing untrusted font data. This approach was problematic, because it meant that if you installed an office suite on a server then you needed to install all of its fonts on every thin client machine, or it needed to do all of the font rendering and then just send images to the X servers. Modern (i.e. for about the last decade) X systems have done font parsing and rendering on the client but stored the rendered glyphs on the server, where they can be composited quickly. This also has the advantage that the same rendering code can be used for any font format without the display server needing to know how it works.
Race is a protected class, and IQ test results show a correlation with race. This makes them count as a racially discriminating test.
I visit Google periodically, and every time I find myself less impressed with the people I meet. I don't know whether this means that I've become immune to the Google mystique, if my standards have gone up, or if they've been lowering their recruiting standards. I do know that the friends of mine who went to work there a few years ago and told me how great a place it was to work and how they were surrounded by smart people and doing interesting and creative stuff are now telling me about bullshit processes, idiot managers, and the places they're thinking of moving to when they quit Google.
I really want to believe that you are exaggerating. Last time I wrote code like that I was 14 (in OPL for the Psion Series 3 originally, then again in C). I've not done any graphics stuff (except for mentoring a summer of code student who was working on some graphics API things) since I finished my PhD, and as little as I could get away with back then, and it still sounds like a trivial problem. I guess it depends on the APIs - presumably they had some kind of set pixel or draw line function (or a frame buffer in memory) available and it wasn't some weird system?
Do Google and Facebook have that many applicants? Their recruiters keep pestering me, and the Facebook one seemed quite disturbingly desperate. Neither seemed like they were swamped with candidates. If you have thousands of qualified candidates for every position, then you don't generally approach more unsolicited...
I had a really good telephone interview for one company. The initial question was impossible, and a few seconds thought made me realise it was impossible. Part of the point was to see how you approach this kind of challenge, when confronted with really bad specifications. The problem - as stated - was impossible, but it was possible to solve it in the cases where people were actually likely to care about the results. I quickly came up with a hacky solution with the proviso that it would be inefficient but may not be worth optimising depending on how it was being used. He then asked me how it could be optimised, and we discussed a few strategies. Most of the half hour interview was focussed on the same problem, but the requirements gradually changed and by the end it was focussing entirely on speed and not caring about 100% accuracy for the algorithm as long as the common cases were very fast.
And, more importantly, remembering printf tells you nothing about the candidate. I could have remembered any of the things the grandparent suggests when I was 11. I can still remember them now. Hiring someone with 11-year-old me's knowledge of C would be a disaster for most companies (I'd like to think hiring me now would be a bit better). This kind of test checks for superficial understanding of the language, but little more. If you're relying on the interview to test whether the applicant has read the first chapter of a C book, then you should reevaluate the rest of your hiring process...
Depends on the complexity of the problems. If they're very simple, any vaguely competent applicant will be able to solve them, but that won't tell you anything because you should have filtered out the ones who couldn't long before they got to the in-person interview. More complex ones will filter people out, but on a criteria that is so far divorced from any relevance to the job that you may as well ask them to paint a picture or compose a song.
And it makes about as much sense as asking an applicant for a job as a truck driver to run carrying a heavy backpack. Sure, the test and the job both involve moving heavy goods, but skill at one is not really related to skill at the other.
A good programmer types largely subconsciously. You think about the structure and your hindbrain makes your fingers translate it into concrete syntax. Move to a board, and now you're consciously thinking about the syntax, and probably consciously thinking about moving the pen, since writing on a board is not something most programmers do regularly.
Simon Crosby is not the creator of Xen. It was created by Keir Fraser while he was doing his PhD, under supervision by Ian Pratt (it was actually created as the result of a drunken bet between Keir and Ian). They then went on to found XenSource, which was bought by Citrix. Simon Crosby (yes, his name does have a y on the end - well edited Slashdot) was brought in to do marketing for XenSource. He had very little to do with the technical side.
On my laptop, Xen is a bit over 650KB, but the initrd image for my kernel is about 11MB.
Two things here. First, the initrd image is a RAM disk containing a recovery filesystem. If you want to compare it to Xen, you need to compare it to the Xen admin tools as well as the kernel - and they are written in Python so come with 5MB of Python dependencies before you even get them to start. Secondly, 90% of the size of any modern kernel is device drivers. Xen does not contain any device drivers - it delegates all of that to the domain 0 guest (or to multiple driver domains).
I'm actually quite surprised that Xen is 650KB. That seems a lot bigger than it should be for what it actually does: schedule VMs to run on the physical CPUs and allocate pages of physical memory to them.
Often, you'd get root on a server because one of the service that is running has flows. Not because of a kernel root exploits. In this case, having things isolated means you'd get root only on a server running a single service
This makes no sense. If you compromise, say, Apache, then you can control Apache, but nothing else. Apache runs in a chroot, so you can't even see the rest of the filesystem. You only get root if there is also a local privilege escalation vulnerability in the kernel, or if the user was stupid enough to run Apache as root (and if they're going to misconfigure services in an OS, what makes you think they won't misconfigure VMs?).
The difference is, mainframes did it properly. The first system to support virtualisation was VM/360. It didn't just support virtualisation, it supported recursive virtualisation. This meant that any VM could contain other VMs, so you could use the same abstraction for isolation at any level. Operating systems provide a very limited form of virtualisation: processes. A userspace process is basically a VM for a paravirtualised architecture. Any time it wants to talk to the hardware, it has to go via the kernel. The problem is, it stops there. A process can't contain other processes which can only contact the kernel via the parent process, so programs end up adding their own ad-hoc isolation mechanisms. Things like the JVM, web browsers, even office apps all need to run untrusted code but have to isolate it without any help from the hardware. Fortunately, modern systems are providing things like capsicum, sandbox, and systrace, so it is now possible to create a child process with very restricted privileges.
Not surprising. Simon Crosby was the CTO of XenSource before it was purchased. He was in charge of marketing. Kier Fraser and Ian Pratt were the two who were in charge on the technical side.
HP could die tomorrow, but LaserJet 4s will be printing until the Sun burns out.
Sun burned out on January 27, 2010...
You seem to misunderstand what the sandbox is. OS X has had a set of APIs for sandboxing applications since 10.5. The sandbox(7) man page will tell you a lot about it. This comes with a few default policies, and you can add more. If you download an app and don't trust it, then you can start it in a sandbox (there's no GUI for doing this, which sucks, but it would be a few hours work to add one).
This isn't an 'authoritarian model' any more than the UNIX process model is: the kernel is the authority and any application has to go begging to it for access to anything. You can ship your own sandbox policies if you want to implement privilege separation and so on in your OS X application, and a lot of Apple's programs use it already, and have for a while - you may remember a mDNSResponder vulnerability that only affected 10.4, because it ran in a sandbox on 10.5. You can see the sandbox definition that mDNSResponder uses and it's pretty trivial to put something similar together for your own daemon.
The only difference now is that Apple is defining a sandbox profile for normal applications and forcing developers to use it if they want their application in the App Store. It is not a whitelist of applications, it's just a default security policy that applications must work with. This is like Microsoft requiring applications to work as non-Administrator users for the Designed For... certification, or a Linux distribution rejecting suid root apps from the default repository.
But, aside from that, he was right?
If the advice is 'don't be a troll' there isn't much harm. Either they'll ignore it or be unable to follow it, in which case it won't do any harm, or they will follow it and we're down one troll...
Of course, if they had fixed it, then you'd be complaining about the federal government interfering in states' issues...
Linux is the most popular brand of POSIX, and mostly, vim is used on it.
I'd have thought OS X was a bit more popular than Linux (and a lot more POSIX compliant - it's actually certified as conforming to the Single UNIX Specification, while I regularly come across places where Linux makes a half-arsed stab at implementing the standard). It ships with vim, although the system vim never gets updated over the lifetime of an OS X release so it tends to be a bit out of date quickly.
I doubt it. I've not come across a system with vi installed as vi for years. BSDs ship with nvi, OS X and most Linux systems ship with vim, although a couple of Linux distributions use elvis. It was a derivative work of the original AT&T ed, which meant that it could only be used by people who had an AT&T UNIX license. It was only a few years ago that the ed code was open sourced and people could start shipping vi, but by this time vim, nvi, and elvis were pretty entrenched, and there wasn't much point in saving a hundred KB on disk.