Weekly Edition
Return to the Security page
| |||||||||||||
World-writable memory on Samsung Android phones
Here's a
report on the xda-developers site stating that Samsung Android phones
have an interesting feature added to the kernel: a /dev/exynos-mem
device, world-writable, that gives access to all physical memory on the handset.
"The good news is we can easily obtain root on these devices and the
bad is there is no control over it." Owners of such phones might
want to be especially careful about which software they install for a
little while.
(Log in to post comments)
World-writable memory on Samsung Android phones Posted Dec 17, 2012 15:54 UTC (Mon) by endecotp (guest, #36428) [Link]
Sometimes I get the feeling that there are only about 3 competent software engineers left on the planet. How could something as egregious as this possibly appear in production code? It gives the impression of people stumbling around copying&pasting code until it "just works" without any real understanding of what they are doing - and zero auditing or code review.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 16:36 UTC (Mon) by nickbp (subscriber, #63605) [Link]
I expect its often an issue of rushing to keep the schedule from slipping, where the engineer had quickly put something together that 'works enough to demo', with plans for a replacement before the final release. But the replacement never happens, since the engineer is told that 'what we have already works!'
World-writable memory on Samsung Android phones Posted Dec 17, 2012 16:55 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]
Probably the best explanation.
Others are:
- Windows let all users do this for years:
- It's easier for a malicious app to just ask for the permissions it wants to do bad things, rather than hack physical memory or bother trying to get root. Most people are going to click OK anyways...
World-writable memory on Samsung Android phones Posted Dec 17, 2012 17:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Not quite the same. The PhysicalMemory device had always been protected by ACLs in Windows, requiring administrative access to read/write to it.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 17:12 UTC (Mon) by ledow (guest, #11753) [Link]
3DFX drivers for Windows basically always allowed the same (they had a system driver / service installed as administrator that allowed unchecked DMA to any memory region) and it was only discovered about 2-3 years ago (i.e. years after everyone had stopped using them because they were obsolete).
FireWire also had similar problems inherent in the design of the protocol itself that allowed systems to read any memory locat
It's pretty common. The question is how hard it is to exploit (i.e. this is incredibly easy, by just installing the "wrong" apk file) and how long it takes someone to find it (3DFX basically "got lucky" in that nobody noticed until nobody was using 3DFX drivers anyway).
World-writable memory on Samsung Android phones Posted Dec 17, 2012 17:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
NVidia on Linux had the same vulnerability until early this year. It's not possible to really control the third-party drivers.
However, in this case Samsung's engineers should have known better.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 17:28 UTC (Mon) by andreasb (subscriber, #80258) [Link]
> FireWire also had similar problems inherent in the design of the protocol itself that allowed systems to read any memory
Every node has its own memory space, but that is an abstract concept with no requirement that it maps to the node's physical memory at all, much less that it maps 1:1 unrestricted. So that is not actually inherent in the protocol.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 17:43 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
Actually it wasn't administrative privileges. Write access to /Device/PhysicalMemory has be exclusively given to the system user and no other user. Now you could add that its trivial to schedule something to run as system if you're administrator but if you're already the administrator what are you messing around with physical memory for. Just install a kernel driver and be done with it.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 19:10 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
> - Windows let all users do this for years:
That's not the case. Normal, unprivileged users were never able to use that device. \Device\PhyicalMemory was no worse than /dev/mem.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 20:13 UTC (Mon) by mikov (subscriber, #33179) [Link]
My experience from most places: nobody cares, nobody reviews. If a problem is discovered later, we will fix it later - why worry now and delay the release? What "/dev/mem"?? Enough with this mumbo-jumbo we have a release to make and management bonuses to earn.
In fact people who do care and worry about esoteric things like "security", or "good design" or "code quality" are universally viewed as trouble-makers or ivory tower idiots both by management and most of the engineers. It is an uphill battle even to do what used to be the baseline 10-15 years ago.
Commercial software engineering now is no different from accounting. The glory days are gone. It is all downhill from now on.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 20:21 UTC (Mon) by mpr22 (subscriber, #60784) [Link] There is nothing new about people being cavalier about code quality. "Real Programmer" jokes (based on stereotypes rooted in truth) are at least 30 years old.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 20:47 UTC (Mon) by mikov (subscriber, #33179) [Link]
20 years ago many developers were self-taught, and really passionate about their work. I think the turning point was around 2000; after that "software development" gradually transitioned into a "9 to 5" job for people with average intelligence who've taken a 3-month course in programming :-)
99% of developers these days have never even heard of Donald Knuth.
Really, I am not bitter :-) I have actually been very lucky in that respect, but I am simply stating the facts as I see them...
World-writable memory on Samsung Android phones Posted Dec 17, 2012 21:32 UTC (Mon) by oever (subscriber, #987) [Link] Oh, if only people were still deriving mathematical proofs about their software!Today's release of HTML5 is, frankly, embarrassing. "HTML syntax" is still allowed and even has quite different semantics just because even minor syntax errors will prevent a document labeled as XML from being rendered fully. There surely are good programmers still, but the noise level has increased as has the need to keep pushing your code if you want it to be used. The general acceptance of sloppy coding (aka duck typing) and tendency to blame the browser, no the coder, has led to a situation where coding is actually harder for everyone. Nevertheles, when it comes to Android security, you have to concur that more thought was put into security on Android than on (GNU/)Linux. On Android each application runs as a separate user. On Linux, this is not the case. In fact: every application can read all user files and dial home as much as it likes. Tools like fakechroot or sydbox may help here.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 11:33 UTC (Tue) by khim (subscriber, #9252) [Link] The general acceptance of sloppy coding (aka duck typing) and tendency to blame the browser, no the coder, has led to a situation where coding is actually harder for everyone. Oh yeah. One simple example: Try to guess what this code will print and why. Who's life became easier when language like this is pushed as a strict requirement?
World-writable memory on Samsung Android phones Posted Dec 18, 2012 20:26 UTC (Tue) by apoelstra (subscriber, #75205) [Link]
That's a shocking example. I had a few ideas about what the output would be, but was pretty sure it would be "H1 e1 l1 l1 o1 ", since I recall that in Javascript, adding a number to a string would convert the number into a string containing the decimal expansion of the number, then append it to the string. (And when you split up a string, you get smaller strings, not characters or some different type.)
Alternately, it might have added one to the characters 'H', 'e', 'l', 'l' and 'o' to get 'I', 'f', 'k', 'k', 'p', but I'm pretty sure Javascript has no character type, let alone one that would act in such a C-ish way. So I didn't expect this outcome at all, though I would in some other languages.
But maybe it would interpret "Hello" as a collection of one string, and output "Hello1". Or it would try to convert "Hello" to something it could iterate over and output "[List]1" or some abomination. Or maybe the body of the loop would never run. Or maybe it would just give an error.
It did not occur to me, though maybe it should have, that i might run through the integers 0, 1, 2, 3 then 4, since "Hello" is a thing containing 5 elements and 'for' will only give you integers. So the output would be "1 2 3 4 5". Maybe this was an accidental behavior in some ancient Netscape and it wound up being baked into the language.
Nope. The actual output is "01 11 21 31 41 51 ". Go figure.
World-writable memory on Samsung Android phones Posted Dec 20, 2012 18:48 UTC (Thu) by sorpigal (subscriber, #36106) [Link] You left out "why" test is an object of type string, and for a string object you can access characters by indexing into it in a looks-like-C kind of way: document.write(test[0]); // H JS for .. in syntax iterates over *keys of an object* From this you can tell that when I say
test = {one: "hello", two: "world"};
for (i in test) alert(i);
expected this will "one" and "two"
test['two'];
And this will be "World" The array object is no different, it just has keys that happen to be sequential numbers
test = ['one', 'two'];
for (i in test) alert(i); // 0, 1
alert(test[1]); // two
In order for the string object to look like a C string and let you index characters it must, obviously from the above, appear to store each character at a numeric key corresponding to its index in the string. The only strange part is why i+1 does string concatenation. I would think that the key would be numeric, but I suppose that there's some reason it isn't. If you need it to be you can use unary +
test = "Hello";
for (i in test) alert(+i+1); // 1, 2, 3, 4, 5 as expected
World-writable memory on Samsung Android phones Posted Dec 21, 2012 2:57 UTC (Fri) by idupree (subscriber, #71169) [Link]
Keys in JavaScript objects are strings. Javascript arrays (and strings) are Javascript objects. Therefore, keys of Javascript arrays are strings (they are string representations of numbers, to be precise, or of non-numbers if you explicitly add non-number keys to an array object).
Yes, it really is that absurd. And no, it doesn't necessarily impact performance, because modern Javascript engines are often smart enough to undo this oddity without changing the language semantics.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 15:00 UTC (Fri) by sorpigal (subscriber, #36106) [Link] it doesn't necessarily impact performance, because modern Javascript engines are often smart enough to undo this oddity without changing the language semantics "Often" is not always; crazy isn't that far behind us. I wonder, now, about the performance of code I've written where complex objects and functions have been used as keys. I imagined I was storing pointers, but if the key is really the stringification of the object... that can't be good. I suppose it sort-of makes sense that somebody decided storing a numeric key as a string was less scary than storing it as a float, but the madness has to stop some time.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 3:06 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
Thanks for explaining, sorpigal and idupree!
I was just telling what I observed - I really didn't have any idea what might have been going on behind it.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 13:07 UTC (Tue) by clump (subscriber, #27801) [Link] Nevertheles, when it comes to Android security, you have to concur that more thought was put into security on Android than on (GNU/)Linux. On Android each application runs as a separate user. On Linux, this is not the case. In fact: every application can read all user files and dial home as much as it likes.Except that of course you know Android is Linux. You're also neglecting to mention MAC/SELinux which allows very fine grained containment of more than just applications. I you want a secure Linux distribution you can have it. Whether many distributions care to take advantage of SELinux, capabilities, sandboxing, etc, is a different story. The abysmal security of Android's typical "Play" store application should give anyone pause.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 15:57 UTC (Tue) by khim (subscriber, #9252) [Link] The abysmal security of Android's typical "Play" store application should give anyone pause. What "abysmal security" are you talking about? Compared to the alternatives it's nirvana. Yes, some trojans are out there and there are a lot of articles which discuss this problem, but most regular users only hear about problems from such articles. Windows, MacOS - these are significantly worse and even Linux has pitiful track record once you go beyond the repos. The only alternatives which are kind-of-better are iOS and Kindle - and somehow I don't think LWN subscriber considers iOS and Kindle a good things to promote.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 21:36 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Self-taught programmers are no better, and can be worse. I am confident that the code I wrote as a self-taught programmer twenty years ago is far worse (in security terms and many other ways) than the code I wrote after an undergraduate degree fifteen years ago. Formal education is a good place to inculcate good practices that lead to better security.
It's the job that makes the difference most of all. Microsoft made a big difference to its security outcomes by emphasising security in the job, giving people the tools to write better code, allowing people to "stop ship" for a security bug, and so on. If Samsung says "It works, who cares?" then that attitude percolates down to the people writing the code and unless they're superheroes they will skimp on security.
If the job isn't great in other ways chances are Samsung also ends up accumulating a lot of non-programmers. It doesn't really matter whether they have a degree, or did a 3-month course, or "self-taught", there are a remarkable number of candidates for entry level programming jobs who cannot write programs. Companies that don't make you write code in interview and don't pre-screen for ability end up with a head count of "programmers" you wouldn't trust to write Hello World. Obviously nobody is going to give the job of writing a Linux kernel driver to the idiot that management hired who struggles to remember to put a semi-colon at the end of lines, but the stress of clearing up after such people can mean those who would get assigned the driver job don't have the time to do it well.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 21:47 UTC (Mon) by mikov (subscriber, #33179) [Link]
I agree with most of what you said, with one huge point: software development is *by definition* self taught. College courses just help with the process possibly by giving some direction and more information.
Programming cannot be taught in the way that accounting is taught for example. It is unique in the sense that it requires solving non standard problems all the time.
World-writable memory on Samsung Android phones Posted Dec 17, 2012 22:45 UTC (Mon) by Jonno (subscriber, #49613) [Link]
Or in other words: Programing is more of an an art than a craft (though sadly most management, and some practitioners, treat it as a craft, whith results such as this).
World-writable memory on Samsung Android phones Posted Dec 18, 2012 8:21 UTC (Tue) by man_ls (subscriber, #15091) [Link] Craft? You are lucky. Here in Spain (and other EU countries) we are still firmly planted in the software factory paradigm, which suggests that software is a manufacturing process in an assembly line. The results are not pretty.Somehow managers here don't get that software is not about automation, but about automating the automation -- a self-improvement process where at each turn the layer below is itself automated.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 1:36 UTC (Tue) by nix (subscriber, #2304) [Link] Companies that don't make you write code in interview and don't pre-screen for ability end up with a head count of "programmers" you wouldn't trust to write Hello World.This is right, but unfortunately fixing it is hard. Pre-screening for ability means that people have to spend ages in crappy jobs filled with nine-to-fivers while getting enough *real* work done on the side that they can pass a pre-screen. Writing code in interviews is an abomination, though it is possible that I'm only saying this because it discriminates against, well, me (I can't think under extreme stress, I don't think very fast, and I have an apparently permanent interview phobia: combine these and I will always ignominiously fail any interview with a coding component). It is certainly true that writing code in interviews says almost nothing useful about the candidate other than that he's not a total incompetent: it certainly can't determine if the code he writes is maintainable, efficient, well-documented, or has almost any other desirable property. Given that it also discriminates against some competent people, and that the set of people discriminated against includes me, I don't think I can approve. I don't know of any way to interview programmers which actually guarantees that you won't get a lemon, or even filters out most of the lemons. "No agencies, personal recommendation only" might well work, but is terribly discriminatory, since it amounts to hiring people because of who their friends are. (Nonetheless, it can work, and is, to be honest, probably the predominant hiring mechanism almost everywhere that isn't growing so fast that it can't rely on just this mechanism or doesn't have legal requirements to use some more open scheme.)
Hiring software professionals Posted Dec 18, 2012 2:16 UTC (Tue) by mgb (guest, #3226) [Link]
Writing code during an interview is a party trick. But then HR seldom goes beyond party tricks when hiring software professionals.
HR can screen out those who are obviously unqualified, but the final hiring decision should be vested in the manager or team leader who will be responsible for the new hire's performance.
Depending on the nature of the project, the manager or team leader may need to spend considerable time selecting his direct reports from available qualified candidates.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 2:29 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
Maybe interviews should have a "What's an example of some of your "best" code and why? Worst?" question. Bonus points for pointing to actual patches/repositories :) .
World-writable memory on Samsung Android phones Posted Dec 18, 2012 18:03 UTC (Tue) by nix (subscriber, #2304) [Link]
Yeah. This is probably pretty common already in free software companies where the applicant came from a free software background.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 2:41 UTC (Tue) by raven667 (subscriber, #5198) [Link]
> I don't know of any way to interview programmers which actually guarantees that you won't get a lemon, or even filters out most of the lemons
I don't think you have any guarantees and that the only way to know is to not be afraid to try. A probationary period or temporary contract with option to hire makes it much easier to learn from your hiring mistakes rather than being paralyzed by fear or making a mistake or stuck with a lemon
well, it worked Posted Dec 18, 2012 4:11 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Yes, I think you're only saying that as someone it might (if you're even right) discriminate against.
I see a lot of these hypotheticals which seem to imagine that employers are trying to figure out who they should hire out of Jamie Zawinski, Linus Torvalds or John Carmack. Oh dear, what if Jamie spends the whole time ranting about a bug in Emacs and forgets to close a parenthesis? What if Carmack mis-understands and optimises for a scenario where half precision incurs a performance penalty but doesn't consider cache effects? Wouldn't it be terrible if our process couldn't detect that these people are like Gods walking among us?
That's the wrong problem. The problem I've actually /seen/ is that applicants often don't know how to write a program.
Our pre-screening with Codility was put in place because interviewing applicants who can't write code was driving people nuts. As you describe, we had previously relied upon the arbitrarily discriminatory but effective method of hiring people who we personally knew could write programs. This had been effective when it was possible, but there are only a finite number of competent people you know who don't already have perfectly nice jobs, and as you get older very few of these people are looking for the sort of entry-level positions where "non-programmer applicants" are a big problem.
All we actually did with Codility was fire off the links, reject candidates who ignored them or stared at the problems without making a serious attempt to solve them, and interview everybody else. Codility gives a good programmer ample time to ace every problem, write their own unit tests, and try to squeeze out better performance - but we were deliberately not trusting a machine to screen for "good", just for "basically competent". We wanted to go into every interview knowing "this application for the programming job can write programs".
And that cut the flood to a trickle. It's really that easy.
well, it worked Posted Dec 18, 2012 9:45 UTC (Tue) by a0273683@ti.com (guest, #83063) [Link]
> Our pre-screening with Codility was put in place because interviewing applicants who can't write code was driving people nuts.
Samsung uses Codility.
I actually just took a Codility screen for the first time via Samsung. I really love Codility over the screen-sharing of other remote code screenings where it is awkward and somewhat traumatizing to have to code while someone is judging your work, especially if you stop to think for a while and don't want to think out loud.
> All we actually did with Codility was fire off the links, reject candidates who ignored them or stared at the problems without making a serious attempt to solve them, and interview everybody else.
That sounds pretty good.
The only problem in my experience with Codility was the way Samsung (and other companies?) was using it. I had 3 different problems to complete in 90 minutes and was not allowed to see my score at the end. I didn't get to attempt the third problem because I ran out of time on the second one (though I completed the first very confidently in ~20 minutes) trying to track down an error. A couple minutes after time expired, I received an email notifying me that I was not a fit for Samsung.
Oh well, if Samsung is looking for quick programmers predominately, then maybe I'm not a fit. And maybe the person responsible for letting all of memory be 666 is.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 12:08 UTC (Tue) by khim (subscriber, #9252) [Link] I don't know of any way to interview programmers which actually guarantees that you won't get a lemon, or even filters out most of the lemons. This one phrase tells me that you have very small experience hiring candidates. Most candidates who come to the interview are totally, utterly incompetent. About 4 out of 5 if not 9 out of 10. If you'll just reject, say, ⅔ of candidates randomly — you'll filter out "most of the lemons". The question is not hot how to "filter out lemons" but how to find out someone who'll be competent enough to rely on. It is certainly true that writing code in interviews says almost nothing useful about the candidate other than that he's not a total incompetent. Yup. But it weeds out incompetents quite nicely thus it's incredibly valuable litmus test. When candidate which supposedly worked with Java for five years is asked to "reverse words in a string without using additional memory"¹) and s/he tries to recall for the five minutes how to change letter in a string you know that said candidate is not someone you want on your team: either resume is a lie or s/he does not keep in mind even basic facts about the stuff s/he's working with every day. Given that it also discriminates against some competent people, and that the set of people discriminated against includes me, I don't think I can approve. And here you are doing the fundamental error. Interviewing is absolutely not about distinguishing good candidates from bad ones. It's not a big deal if some given approach will lead to rejection of 50% of good candidates if it'll guarantee that it'll reject 99% of bad candidates, too. It is much, much better to reject a good candidate than to accept a bad candidate. Good candidate will find acceptable place to work anyway (or else he's not a good candidate but just someone who just thinks he's good), so there are no problem with rejection but if bad candidate is accepted… well we are observing the result, don't we? ──────────
World-writable memory on Samsung Android phones Posted Dec 18, 2012 14:36 UTC (Tue) by ekj (guest, #1524) [Link]
That depends on the job-market. Over here, there's a lack of suitable candidates, thus rejecting candidates who would've been a good, or even a reasonable fit, can be a pretty big deal.
Sure, hiring a entirely hopeless case is probably going to be worse, but most of the time we hire people on a 6-month probation-period, so the downside is somewhat limited. (if we can't detect them being bad in 6 months of full-time work, they can't be all -that- bad)
World-writable memory on Samsung Android phones Posted Dec 18, 2012 16:06 UTC (Tue) by khim (subscriber, #9252) [Link] That depends on the job-market. Over here, there's a lack of suitable candidates, thus rejecting candidates who would've been a good, or even a reasonable fit, can be a pretty big deal.Even if the job market is tough it's still much better to reject good candidate and leave your team understaffed rather then to give to them someone who'll drag them back. Sure, hiring a entirely hopeless case is probably going to be worse, but most of the time we hire people on a 6-month probation-period, so the downside is somewhat limited. Bad candidate left unsupervised can create a lot of problems for your company in the future in one day (how much time is needed to create the abomination we discuss here?) and if you constantly supervise him (or her) in these 6 months then you are effectively interviewing him (or her) for the duration of these 6 months. Do you really think it's sensible approach to spend valuable time of senior engineers for this constant interviewing when they could do 5-10 simple interviews in that time instead? Or do you live in the area where you can not find even 10 candidates in 6 months? In this case perhaps it's better to move your operations in other place or at least try to understand why candidates avoid your particular company specifically.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 18:19 UTC (Tue) by nix (subscriber, #2304) [Link] Even if the job market is tough it's still much better to reject good candidate and leave your team understaffed rather then to give to them someone who'll drag them back.That depends entirely on how understaffed your team is, in both relative and absolute terms. A team making no progress because it has too few members and they are all off sick is a team with an effective zero members.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 20:24 UTC (Tue) by khim (subscriber, #9252) [Link] That depends entirely on how understaffed your team is, in both relative and absolute terms. No. It really does not. I've seen this reasoning applied few times when we hired candidate we had doubts about and in almost all cases this was a mistake. A team making no progress because it has too few members and they are all off sick is a team with an effective zero members. Yes. But such team is still just making zero progress. With a bad enough employees team will make negative progress instead which is worse then zero.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 18:22 UTC (Tue) by nix (subscriber, #2304) [Link] Or do you live in the area where you can not find even 10 candidates in 6 months?This depends on the difficulty of the task. In my current role, we've been searching for candidates globally more or less continuously since I joined, with a multinational company's job search process behind it. The job requirements are arcane enough that applicants are few and far between, and successful applicants rarer yet. Now maybe we'd have lots of applicants if we could search Asimov's Galactic Empire, but unfortunately we don't have 25 million inhabited planets to add to our search process. We're stuck with this one. And this is not a terribly rare case. A lot of companies are hurting for qualified staff.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 20:18 UTC (Tue) by khim (subscriber, #9252) [Link] The job requirements are arcane enough that applicants are few and far between, and successful applicants rarer yet. We had such problems in the past, too. If job requirements are so arcane then you can not find enough candidates then you need to change something. Sometimes you just need to pay more, sometimes you need to accept the fact that you'll be unable to find someone who satisfies your job requirements exactly and will need to broaden them (and then spend some effort to raise newbie to the original level of job requirements). What you should not do is to lower requirements arbitrarily in the middle of the interview process just to hire "somebody, anybody to fill this %#^%^&*@#@ vacancy". Once you understand that "10 years of experience working with Renderscript" is not something you actually need you suddenly find lots of suitable candidates. Enough if them to pick ones who can code and can talk with you meaningfully (I assume the position indeed has something to with programming: it's quite pointless to ask candidate to write code if you are hiring an art-director).
World-writable memory on Samsung Android phones Posted Dec 19, 2012 21:19 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> And this is not a terribly rare case. A lot of companies are hurting for qualified staff.
I wonder if this is due to the messes that underqualified staff hires from the past created.
World-writable memory on Samsung Android phones Posted Dec 20, 2012 0:03 UTC (Thu) by nix (subscriber, #2304) [Link]
Certainly not where I work :) in my experience, the places that hire underqualified staff are probably happy to continue to do so (they have a competence floor, but it's lower than the expert shops).
Or are you suggesting some way in which underqualified hires can somehow... breed other underqualified staff? In the absence of bogon supercolliders (or, well, actual human breeding) I don't see how that's possible. Am I missing your point?
World-writable memory on Samsung Android phones Posted Dec 20, 2012 0:43 UTC (Thu) by hummassa (subscriber, #307) [Link]
> underqualified hires can somehow... breed other underqualified staff?
My experience is that underqualified hires kind of breeds more underqualified staff by the following process: more-qualified staff (QS) can't fix the messes done by the underqualified staff (US); QS gets overwhelmed with work requests (everyone wants QS on the job), its work becomes of lesser quality (effectively turninq QS into an overworked US); time passes and US gets more and more UNDERwhelmed with work requests and this affects QS's motivation to work (I work well, people put me to work a lot, and I can't take my vacations with my children because they put the payroll system under my responsability, etc... while Joe surfs the web the whole day, never leave one minute and a half past five and takes the whole July vacationing.) driving QS's work quality still further down, etc. etc...
World-writable memory on Samsung Android phones Posted Dec 20, 2012 3:23 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
> Or are you suggesting some way in which underqualified hires can somehow... breed other underqualified staff? In the absence of bogon supercolliders (or, well, actual human breeding) I don't see how that's possible. Am I missing your point?
I read "companies are really needing qualified staff" and wondered if the need was caused by the process of cleaning up the unqualified staff's messes. The unwritten part was "if companies hadn't hired unqualified staff in the first place, maybe they wouldn't need 10 competent people, just one or two".
World-writable memory on Samsung Android phones Posted Dec 20, 2012 14:50 UTC (Thu) by nix (subscriber, #2304) [Link]
Ah. That's true enough, though it's amazing how much mess even one qualified person can clean up (though 'qualified' is really the wrong word: 'competent and motivated' is more important).
World-writable memory on Samsung Android phones Posted Dec 19, 2012 17:11 UTC (Wed) by nye (guest, #51576) [Link]
>Bad candidate left unsupervised can create a lot of problems for your company in the future in one day (how much time is needed to create the abomination we discuss here?)
That abomination made umpteen millions (billions?) of dollars. That can buy rather a lot of time spent fixing it.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 16:22 UTC (Fri) by khim (subscriber, #9252) [Link] I'm not talking about Exynos here but about these libraries which use peek/poke interface to access camera. Do you mean someone actually bought phone because it contained proper implementation of peek/poke interface from 30 years ago? News to me. Perhaps you imply that this was purposefully inserted as some kind of backdoor and the person in charge receive huge bribe? That's pretty heavy accusation. No, I doubt it's anything that sinister. More likely then not someone just made it because it solved their immediate problem and they refused to even think for a second about consequences.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 17:12 UTC (Fri) by hummassa (subscriber, #307) [Link]
> I doubt it's anything that sinister.
I suppose Hanlon's razor apply here.
> More likely then not someone just made it because it solved their immediate problem and they refused to even think for a second about consequences.
Even if the engineer warned someone of the consequences, middle management deemed those inconsequential... =D
World-writable memory on Samsung Android phones Posted Dec 21, 2012 17:30 UTC (Fri) by khim (subscriber, #9252) [Link] Even if the engineer warned someone of the consequences, middle management deemed those inconsequential... =D And they were right! This was engineers mistake, not a management one. Someone probably forgot about Iceberg principle and showed demo which looked good enough to be released. Don't do that! Management is not competent enough to discuss such things. Don't ever forget about the rule: build your UI in such a way that unfinished parts look unfinished. It's surprising how often seemingly competent software engineers forget about this simple rule and how much grief this produces in the end.
World-writable memory on Samsung Android phones Posted Dec 22, 2012 11:40 UTC (Sat) by lab (subscriber, #51153) [Link]
> Someone probably forgot about Iceberg principle and showed demo which looked good enough to be released. Don't do that! Management is not competent enough to discuss such things. Don't ever forget about the rule: build your UI in such a way that unfinished parts look unfinished.
> It's surprising how often seemingly competent software engineers forget about this simple rule and how much grief this produces in the end.
Oh my God. I'm highly embarrased to admit, that only now did I read that piece for the first time. I'm banging my fist against my forehead, for making this mistake so many times, and getting frustrated by it. Thing is, as a programmer I have been in denial about my surroundings really being that 'stupid', and refusing to accept it. But it's blindingly obvious, and I've known it all along. I think you (well, Joel) just saved a good chunk of my sanity going forward.
World-writable memory on Samsung Android phones Posted Dec 26, 2012 22:29 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
The implications for the design phase are fairly important too.
Our UX person prototypes things with pieces of paper printed in a haphazard way. Instead of a flashy series of screens, the users are looking at pieces of paper they can cut up with scissors or scribble on with a pencil, and as Joel points out, they can't help but notice that none of this _exists_ yet, it's just pieces of paper and so they don't get the erroneous impression that it's set in stone and asking to change it will mean a delay or increased costs.
The haphazard printing also means when your question is "Is this phrasing clear?" or "How should these things be grouped?" you don't get feedback about typography, iconography, image formats, or how slow the demo machine is.
World-writable memory on Samsung Android phones Posted Dec 27, 2012 9:31 UTC (Thu) by hummassa (subscriber, #307) [Link]
I had a boss that had an incredible difficulty with that. Whenever I built an electronic prototype, he wanted to ship it, and I had to explain that the thing did not work, just gave the illusion of working... And then he wanted to know why I was "wasting my time" with the prototype...
World-writable memory on Samsung Android phones Posted Dec 18, 2012 18:17 UTC (Tue) by nix (subscriber, #2304) [Link] This one phrase tells me that you have very small experience hiring candidates. Most candidates who come to the interview are totally, utterly incompetent. About 4 out of 5 if not 9 out of 10. If you'll just reject, say, ⅔ of candidates randomly — you'll filter out "most of the lemons".I assumed that it was bleeding obvious that I wanted to keep as many non-lemons as possible. Otherwise, you could filter out 100% of the lemons by just rejecting everyone, or better yet saving a lot of money and never starting the hiring process at all. "reverse words in a string without using additional memory"And here you see how vague questions can cause trouble. I spent some seconds thinking on that one before realising that you probably did not mean what you said, but rather 'without explicitly (at the bytecode level or above) mutating storage that scales as the length of the String' (since you probably can't avoid *all* object storage mutation without writing your own javac). The downside of this description is that it will confuse the heck out of most people :( but without it... ... it is easy to reverse words in a String of known length in Java without allocating memory during the reversal process: ensure that you have a big enough StringBuffer available first, as working space (a good move for performance reasons anyway). It is possible to reverse words in a string of known length in Java without allocating more bytes of String than you had allocated at the start: make sure you lose all references to the original String and GC before making the String you return in: sometimes you need to do this if your String is very large. It is impossible to do anything in Java without the possibility that the VM will choose to allocate additional memory on the OS or C library level. Good candidate will find acceptable place to work anywayYeah, but only once he finds a place that isn't using such a scheme to rank candidates.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 20:07 UTC (Tue) by khim (subscriber, #9252) [Link] I assumed that it was bleeding obvious that I wanted to keep as many non-lemons as possible. Why would I want to do this? Otherwise, you could filter out 100% of the lemons by just rejecting everyone, or better yet saving a lot of money and never starting the hiring process at all. Now we swing to the other direction — which is equally pointless. You don't need billion employees, you just need a few of them. May be ten, may be thousand, may be even million (but I would like to see the project which needs million of software engineers), but much less then there are good candidates. As long as your process gives you enough—it's fine and you can try to optimize it further. If it's not gives you enough—then you are in trouble. "reverse words in a string without using additional memory"And here you see how vague questions can cause trouble. EWORKS_AS_EXPECTED. You see, the goal of the whole process is to hire someone for your team. If the candidate is some genius but can not work with real people (who often say things vaguely or sometimes even wrong) then you don't want to hire him. ... it is easy to reverse words in a String of known length in Java without allocating memory during the reversal process: ensure that you have a big enough StringBuffer available first, as working space (a good move for performance reasons anyway). It is possible to reverse words in a string of known length in Java without allocating more bytes of String than you had allocated at the start: make sure you lose all references to the original String and GC before making the String you return in: sometimes you need to do this if your String is very large. This is good answer. It will show to me that the candidate has good working knowledge of Java but does not know computer science terminology (or purposefully ignores it). This basically means that he's the aforementioned genius (who can do amazing things but will have trouble communicating within a team). I will probably want to see the code anyway and then try to understand if the chasm between our terminology viewpoints can ever be bridged. It is impossible to do anything in Java without the possibility that the VM will choose to allocate additional memory on the OS or C library level. Wrong. It's impossible if you use immutable classes like String but quite possible if you'll use char[] instead. If you want to do such transition or not depends on the task in question. One place where you need to understand this difference is if you'll want to try to run your program on a JavaCard which has no GC and no free (yes, Java without GC! endorsed by Sun! and they talk about fragmentation after that? gosh). Yeah, but only once he finds a place that isn't using such a scheme to rank candidates. It's not your problem. If all the places will start using such scheme then it'll just mean that ability to pass such interviews are now part of what the "good candidate" definition it.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 20:28 UTC (Tue) by nix (subscriber, #2304) [Link] I think we're arguing fiercely for the same thing in different words in most areas. However...You're wrong, sorry. There are no guarantees at all in the language specification regarding when the VM will choose to allocate memory on the OS or C library level (nor should there be). Thus, you cannot be sure that anything you choose to do, or not do, in Java will or will not allocate memory on that level, though there are things you can do to roughly influence patterns of allocation and allocation rates. You could perfectly well find that your char[] access caused some VM-internal counter to exceed some threshold and a JIT to be kicked off, which would surely allocate memory on the C library level and quite possibly on the OS level as well. (Indeed, I've seen just this with simple integer additions). So you must define what you mean when you say 'without using additional memory', or you should expect to be misinterpreted.It is impossible to do anything in Java without the possibility that the VM will choose to allocate additional memory on the OS or C library level.Wrong. It's impossible if you use immutable classes like String but quite possible if you'll use char[] instead. If you want to do such transition or not depends on the task in question. A JRE can legitimately start thrashing or run out of OS-level memory (and get killed or throttle itself) while executing nothing on the bytecode level but a loop which adds two numbers together. It's unlikely, but it's possible. And OS-level memory is a form of memory one often cares about running out of, even if you can't control it precisely from the bytecode level or above (though JRE command-line parameters can restrict it to some degree, in some implementations). One also cares about running out of memory on the JRE level, not least so as to avoid running into the artificial limits imposed by those command-line parameters. One also cares about minimizing garbage production rates. These are all different problems, with different solutions and different tradeoffs involved. Yet you just said 'memory' and expected us to tell by telepathy which one you meant. But that depends on what problem you're trying to solve! It's not your problem.It bloody well is my problem if I'm one of the candidates your proposed scheme discriminating against! Indeed it has been my problem for many years. (And I'm not by any means the only person with this problem. It's not incredibly common but it is hardly rare. Yes, most people you'll find applying for jobs in the software community are quite good at interviews -- but that's because those of us who aren't never switch jobs until they become intolerable, and get penalized severely in financial terms for that forced decision.)
World-writable memory on Samsung Android phones Posted Dec 21, 2012 17:18 UTC (Fri) by khim (subscriber, #9252) [Link] There are no guarantees at all in the language specification regarding when the VM will choose to allocate memory on the OS or C library level (nor should there be). Thus, you cannot be sure that anything you choose to do, or not do, in Java will or will not allocate memory on that level, though there are things you can do to roughly influence patterns of allocation and allocation rates. Right. That's serious problem with Java and that's why I'm not big fun of this crazy language. However if you are Java programmer and you claim if you know how to use the beast then you must know how to use it in real world and not just in the programming contests —and that means you should understand when real-world implementation are likely to need memory and when they tend not to need it. A JRE can legitimately start thrashing or run out of OS-level memory (and get killed or throttle itself) while executing nothing on the bytecode level but a loop which adds two numbers together. Not all JREs do that. Aforementioned JavaCard JRE does not. And this problem is generally way, way, WAY too deep to discuss when we are talking about simple mundane tasks. But if the candidate wants to raise it and spend his valuable time discussing it—who I am to object? Just like with real work: you are free to discuss hypothetical problems with JVM, JRE and Intel's microcode when you are asked to create couple of simple forms, but in the end you must provide code in reasonable time and of reasonable quality or else your are not very useful, right? So you must define what you mean when you say 'without using additional memory', or you should expect to be misinterpreted. Absolutely not. Interview process imitates work process in miniature. Someone who's genius and can solve any problem if you'll manage to formulate it precisely enough but will write code which will destroy your whole project if you'll miss one minute detail is someone who's just to dangerous to have around. Yet you just said 'memory' and expected us to tell by telepathy which one you meant. No telepathy, just common sense. You are correct that the task is not precisely formulated, yes. But that's half of the point! Your co-worker (and thus any good candidate) should catch cases where task is not defined precisely enough but s/he should not exhaust you with bazillion questions. If you need to spend two days to write precise spec for the task which only needs two hours to implement then you are better off without such a co-worker, right. In this particular case the good approximation will be "no additional memory in computer science sense" (that is: you only care about memory explicitly allocated by your program, but don't care about JIT details), but if you can meaningfully offer some other idea—that'll give you bonus points. When someone applies his deep knowledge of JVM, JRE, Linux or any other technology to try to solve the task—that's good, it can only be commended, when someone tried to use the same knowleadge to screwup his coworkers… sorry, this something we don't need here (and I doubt there are companies who would want such behavior). Oh, the second half of the point is the question is the ability to actually code solution for the agreed-upon task. It may be slightly different depending on the discussion, of course.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 22:09 UTC (Fri) by nix (subscriber, #2304) [Link] However if you are Java programmer and you claim if you know how to use the beast then you must know how to use it in real world and not just in the programming contests —and that means you should understand when real-world implementation are likely to need memory and when they tend not to need it.You clearly have no idea how complex modern JVMs are. That's bordering on impossible, particularly with the server-mode JVM: you can never tell when the optimizers will kick in. Interview process imitates work process in miniature. Someone who's genius and can solve any problem if you'll manage to formulate it precisely enough but will write code which will destroy your whole project if you'll miss one minute detail is someone who's just to dangerous to have around.In a work situation, you have context -- you are normally formulating and answering these questions yourself, or if helping someone else you both have a common goal in mind. That context defines the level of problem and solution to aim for (that sort of experience is perhaps the major difference between experienced and inexperienced programmers). In an interview, you have no such context -- substantially more precise questions are thus called for.
World-writable memory on Samsung Android phones Posted Dec 23, 2012 13:30 UTC (Sun) by khim (subscriber, #9252) [Link] You clearly have no idea how complex modern JVMs are. I know enough to hate this abomination (it promises to save development time—but then it sucks debugging time for the reasons you've outlined so well thus I'm not at all sure it's a net win), but that's not the point. That's bordering on impossible, particularly with the server-mode JVM: you can never tell when the optimizers will kick in. And so what? Look, if we want to write any kind of program intended to be used by non-programmer (directly or indirectly) then we need to understand how many resources it'll need. Doubly so if we can expect programmer who tries to break our creation instead (most server software for publicly accessible site). For one simple reason: resources cost money! Depending on our task 1GB of excess memory may be not a big deal (if it's a single instance on a single server) or be huge drag on the resources (if there are 100'000 nodes in use). Or it may be even a deal-breaker if we plan to support smartphones with 512MB memory. If we can't do that for one reason or another then such program and such language can not be ever used in production because you can not predict how and when they'll fail. They can only be used in interactive development process: since failure in this case means human programmer must do something and human is resourceful thus it's probably Ok (if worst comes to worst human can use some other means to reach the same goals). But to give the result to the Joe Average or to run stuff in production you must know how many resources it'll need in which cases. If JVM can not be bound by a reasonable limits then it must be replaced, if Java programmer can not write code which is bound to reasonable limits then he should not be hired. It's as simple as that. "No additional memory" is often an approximation when you program in Java, sure, but that's useful approximation so why not use it? You may showcase your deep knowleadge of Java, JVM and other related things as much as you want but if you refuse to accept simple facts of life as they apply to your work then it just means that In a work situation, you have context -- you are normally formulating and answering these questions yourself, or if helping someone else you both have a common goal in mind. You want to imply that said context suddenly jumps in your head when you first come to work in a new team? Nope: you need to poke around, talk with a team members, understand what goes on here, etc. And you need to balance you inquisitiveness with the fact that team members are busy (or else they will not need a new member if they have lots of spare time). In an interview, you have no such context -- substantially more precise questions are thus called for. Absolutely not. As everyone knows there are only two major requirements for the candidate:
World-writable memory on Samsung Android phones Posted Dec 23, 2012 15:28 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> we need to understand how many resources it'll need.
This is one area where theory and practice differ.
Yes, you need to have some idea of how many resources it'll need, but that can be a matter of trying to run the resulting program a bunch of times and seeing how it works, it doesn't need to be predeicted from the code.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 19:26 UTC (Mon) by khim (subscriber, #9252) [Link] Yes, you need to have some idea of how many resources it'll need, but that can be a matter of trying to run the resulting program a bunch of times and seeing how it works, it doesn't need to be predeicted from the code. This is good way to fine-tune your requirements, but you need to have rough idea about whether you'll need 1GB, 1TB, or 1PB from the beginning. Before first line of code is written, in fact.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 17:27 UTC (Mon) by paulj (subscriber, #341) [Link]
Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. At least for a programmer. Yes, you can make an analysis of what would be the required amount, but this is just a lower-bound. The JVM has, for good reason, an extra-ordinary level of freedom in what it does. It could vary from doing GCs frequently in order to be as conserving of memory as possible (at cost of performance), to very infrequently and using far far memory than what you anticipated (trading space to gain time/performance).
If I were given a question by an interviewer that led me then to explain these trade-offs in reply, and that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet...
World-writable memory on Samsung Android phones Posted Dec 24, 2012 19:49 UTC (Mon) by khim (subscriber, #9252) [Link] Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. No. He uses said "simple fact" as an excuse to avoid discussions about real problem. Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And JVM complexity is most certainly no excuse. Sure, it makes said task harder, but so what? It's still a strict requirement. If I were given a question by an interviewer that led me then to explain these trade-offs in reply, If you'll take a look on the initial question you'll see that it has nothing to do with all these complexities. Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous—but ball was in Nix's court. Nix raised JVM-introduced problems with JIT, GC and other horrors. And instead of simple and sensible suggestion to ignore all these problems (good approximation for the first try) he raised them to central position of the task. Well, if you want to discuss these things (instead of limiting our exposure to them by using some rough estimates), then I'm ready to do that, too—but it still does not free your from the need to solve this task. And that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet... Good for you. Perhaps you'll find a place where people always enunciate all the tasks precisely and unambiguously. Perhaps such places do exist, but I've not seen them. In my experience the ability to refine requirements of the task is half of what I do when I write programs. Often the ability to write the code itself is less important compared to the ability to understand WTH we are trying to create in first place and what kinda trade-offs are there.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 21:27 UTC (Mon) by paulj (subscriber, #341) [Link] Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Really? :) Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous - but ball was in Nix's court. … In my experience the ability to refine requirements of the task is half of what I do when I write programs. I agree 100% with the latter statement. Refining requirements is critical, it takes time and usually at least several communication roundtrips, if not many more, in working out all the hidden assumptions that each side has. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. But hey, YMMV - whatever works for you. I'm sure at least some of your competitors will be glad to hire at least some of the "No Hires" who you find to be questioning ;).
World-writable memory on Samsung Android phones Posted Dec 26, 2012 17:54 UTC (Wed) by khim (subscriber, #9252) [Link] And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Knowledge of JVM/system level allocation are great, but these not a replacement for common sense. Joel said it better then me: Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute. Now, go back and think. Do all these discussions about JIT, system level allocations, etc look like something academic about a problem? Well, that's the problem right there. Now, I'm not saying that nix does not Get Things Done, more likely then not he just does not know how to adjust his knowledge to the situation of the interviewing process where interviewer have 45 minutes to say "Hire" or "No Hire", but well… it's his problem, not mine. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. Well, that's why interviews must be conducted in person (even VC is not a good replacement although it can be used as “last resort” kinda thing). When someone tries to dig “too deep” (and discusses pieces which are not really all that relevant to the task on hand) or “too shallow” (and ignores most corner cases) you can quickly try to resolve the situation before it'll escalate. If someone raises JIT-related concerns then it's not plus or minus by itself! The next step is critical: if person says something like “well, usually these are not a problem on practice, let's forget about them for now” then it's big fat plus (interviewee knows about Leaky Abstractions problem but it knows when not to talk about them), but if person goes on to discuss all these minutiae details and abandons the initial task entirely… it's not a good thing to say the least. It's much harder to do discuss these things on forums like LWN: no visual contact and no 45 minutes restriction.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 22:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question.
you can repeat it all you want, but in the real world things are not always this rigid or predictable and you are wrong to state it as an absolute. I'd say that most release managers won't even ask you about resources, let alone refuse to accept something without the requirements tightly specified.
A huge number of companies don't measure this sort of thing ahead of time, they throw it up and buy more hardware as needed, only addressing the efficiency (and resource consumption) when the cost of providing enough hardware becomes a problem.
This smacks strongly of premature optimization.
Yes, there are times when the resource utilization really matters, but much of the time it doesn't matter that much, and other pressures (like time to market) matter much more.
World-writable memory on Samsung Android phones Posted Dec 26, 2012 18:20 UTC (Wed) by khim (subscriber, #9252) [Link] I'd say that most release managers won't even ask you about resources, Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process. let alone refuse to accept something without the requirements tightly specified. Who said anything about "tightly specified"? It depends on what we are releasing. If it's some addon to the 100'000 servers cluster which produces better statistic then estimate “will need no more then one additional server of regular capacity” may be perfectly good estimate but if it's something like “will need additional 3% of RAM” then it may be a big deal (3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look). In the end it's all about the money: if money lost (or “found” if we are measuring sales) are below certain threshold then, of course, resource consumption becomes a moot point, but when we are talking about services which have hundred millions of users then this threshold can be surprisingly low. Yes, there are times when the resource utilization really matters, but much of the time it doesn't matter that much, and other pressures (like time to market) matter much more. My experience is direct opposite. Yes, sometimes you only need rough estimate and don't care about 2x difference in memory or speed but you always care about 1000x difference. And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).
World-writable memory on Samsung Android phones Posted Dec 26, 2012 18:58 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).
I see a lot of stuff deployed without any consideration of these criteria.
> 3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look
This is what I was saying about not bothering about it until the cost becomes significant to care.
I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources
> Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process.
don't make the assumption that every place (or even every large company) is like yours.
In an ideal world, these things would be considered, but in the real world it's frequently put out there on the basis that "it worked with a single user hitting it on the development machine" and only after mistakes take down production "too many times", does there start to be attention to resource usage.
World-writable memory on Samsung Android phones Posted Dec 27, 2012 20:50 UTC (Thu) by khim (subscriber, #9252) [Link] I see a lot of stuff deployed without any consideration of these criteria. Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come. You may be “first to market” but if your stuff stops working after 10'000th user (or after 100'000th user) then you are usually eaten alive by someone else who was second (or sometimes even third). Your only hope at this point is to sell this mess to someone with deep enough pockets and hope that redesign will survive. It rarely does. I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources. Well, that's why I'm talking about back-of-the envelope calculations. Quite often you only need to know resource usage very roughly. But it's one thing to estimate them imprecisely and explicitly refuse to spend time for too much fine-tuning and it's totally different thing to ignore resource requirements completely and not to even know if you need 10 times more servers with 10 times bigger userbase or 100 times more servers. I think the only programs where you can explicitly refuse to think about rough estimates are some parts of games: there are a lot of not-all-that-time-critical stuff where you can use Lua or Python and N does not grow so your requirements don't grow either. And gamedev is not something we are doing here. don't make the assumption that every place (or even every large company) is like yours. I'm not doing that! Not even close! I know there are a lot of companies and a lot of so-called “software engineers” who don't care about this stuff. That's their choice. We just don't want to see these aliens from parallel universe landing in our world, that's all. Take a look on the title of this article—it explains what goes on pretty succinctly (why would you are about time to reference memory if you don't know roughly how many times you'll need to do that in your program?). It does not mean that people are obsessed with all these numbers and complexities all the time—of course not. Often you just note something like “Ok, this is O(N) so will probably not be a bottleneck” or “fine, it's O(N³) memory, but we don't expect to ever see N > 10 thus it's Ok” in your head and happily go on with the implementation. Sometimes you need to actually stop and think if you want to fight for the smaller memory consumption or latency. But you usually do that at the design phase when changes are cheap and simple not when everything is deployed and the only way to fix something is try to add bazillion caches (and even they often don't help).
World-writable memory on Samsung Android phones Posted Jan 4, 2013 22:32 UTC (Fri) by nix (subscriber, #2304) [Link] Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come.Sorry, that's rubbish. It may be true for mass-scale web software with millions of simultaneous users, but most software is not like that! I've written software in which I chose to use really crappy sorts in slow interpreted languages because I knew perfectly well that N for this application could never be above 16 without other invariants being invalidated that would necessitate rewriting the entire application. And this was for a major international bank throwing who knows how many billions of dollars a day around. I think that could be considered 'commercial software' (even if said bank *did* then proceed to shag itself and the economy of a major first-world nation, it was no fault of this software: that division was making money hand over fist and the software worked fine). (Of course, I had to pay attention to time and space complexity at times, and I frequently lamented the way my co-workers could not be bothered to do so. But that doesn't mean that you can always look at the complexity of an algorithm and conclude that you know something about the resource requirements of the system on which it sits, particularly if there are complex layers like modern server-class JVMs in the way. Note that particularly for time complexity all software has such layers in the way, because of the storage hierarchy; context switching and multicore architectures just make it worse, and virtual memory can make reasoning about space complexity into a rat's nest at times too. That's not to say you can't reason about it, but you certainly can't assume that an apaprent efficiency or inefficiency at one level translates into the same all the way up the stack.)
World-writable memory on Samsung Android phones Posted Dec 20, 2012 7:17 UTC (Thu) by ekj (guest, #1524) [Link]
Why would you like to keep non-lemons ? Is this a trick question ? You'd want to keep the good candidates for the same reason you started a hiring-process in the first place: because you're in need of more qualified employees. (and most of the time, you'd prefer them -now- rather than in a decade)
Furthermore, your requirements, or your job-market, or both, may be such that the supply of non-lemons is limited. If you've had the position well-advertised for half a year, and 8 people have applied - one of which is an actual good fit, then rejecting him may mean spending another half-year looking for a suitable candidate.
World-writable memory on Samsung Android phones Posted Dec 20, 2012 15:32 UTC (Thu) by fatrat (subscriber, #1518) [Link]
Have just run an interview processs.....
We included a basic programming test. I mean really basic. Like "write a fib generator" type basic. And one of the three candidates got it wrong even though their CV made it seem like they were a good coder.
World-writable memory on Samsung Android phones Posted Dec 20, 2012 15:47 UTC (Thu) by ekj (guest, #1524) [Link]
Sure. Nobody contests that there's a lot of lemons. My issue was with the person who said "rejecting *non-lemons* is no big deal", and even asked why you'd want to keep them.
Depending on your circumstances it very well may be a fairly big deal.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 4:07 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
> Sure. Nobody contests that there's a lot of lemons. My issue was with the person who said "rejecting *non-lemons* is no big deal", and even asked why you'd want to keep them.
Looking at the quote again:
>> I assumed that it was bleeding obvious that I wanted to keep as many non-lemons as possible.
It's not that "rejecting non-lemons is no big deal". It's that getting a 100% lemon detection with some false positives is more important than doing 95% lemon detection to push the false positives down to zero. The lemons can be such a drag on the process that it's worth losing a few potential candidates than wasting any more time than necessary on lemons.
> Depending on your circumstances it very well may be a fairly big deal.
Of course[1]. If you're looking for 10 people and there are only 10 good people, be prepared to carefully filter out dozens of lemons. If you're looking for 2, setting the bar so that only 5 pass is better than setting it too low and getting all 10 good people and one or two lemons thrown into the mix.
[1]If you have a case where context doesn't truly matter, you should start looking for some asphyxiated spherical cows.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 16:38 UTC (Fri) by khim (subscriber, #9252) [Link] If you're looking for 10 people and there are only 10 good people, be prepared to carefully filter out dozens of lemons. This an example of "asphyxiated spherical cow". Such situation just never happens. Never. It's either "you are looking for 10 people and there are just one or two good candidates in the whole world" or "you are looking for 10 people and there are dozens of good candidates". In first case you need to rethink your strategy (why exactly do you need these candidates? perhaps it's time to change your plans and look for candidates with somewhat different qualifications?) and the second case it's not a big deal if you lose 50% of non-lemons. Even if you somehow in the situation where you need 10 people and there are exactly 10 good candidates in the whole world it's extremely bad idea to organize contest to find them all. What if half of them will be snatched by a competitor? What if your company will grow and will need 20 of them? What if, god forbid, one of them will die? You'll be screwed, that's what!
World-writable memory on Samsung Android phones Posted Dec 18, 2012 23:11 UTC (Tue) by job (guest, #670) [Link]
So you give candidates a trick question for which there is no answer and determine that 9 out of 10 candidates are "incompetent". I don't think that reflects very well on your hiring process, nor your company if I am to be honest.
I got very unsure and was about to ask you for the right answer when I read the footnote. And that's from the comfort zone of my sofa, not a stressful interview situation.
World-writable memory on Samsung Android phones Posted Dec 18, 2012 15:36 UTC (Tue) by Wol (guest, #4433) [Link]
We used this sort of trick ages ago. I think we had four questions on our paper. And we simply wanted to compare programmers.
But the glaring incompetence it threw up was absolutely amazing! We made a point of saying "there isn't enough time to do the test justice, we just want to see if you've got the basics", but the number of people who took great trouble over question 1 and never got to the other three, or the people who completely misunderstood all the questions, or ...
The real corker was ten lines of code we lifted from one of our programs. The question was "what does this code do, could you do better?". Someone had effectively rewritten the int function. I think only ONE person said "hey, this looks like the "int" function, I could do it in one line". Everyone else simply started rewriting it without determining what it did first ...
A basic test can show up a lot ...
Cheers,
World-writable memory on Samsung Android phones Posted Dec 18, 2012 1:25 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh, really? I started out in the working world in 1996. Even then 95% of the people I worked with were nine-to-fivers with no joy-in-coding at all -- and this was perhaps the peak time for skilled software development in the UK, when those of us who grew up with programming courses on national TV were just coming out of university.
Only in elite software development houses (and operating systems development is certainly elite/specialized in this sense) and in major tech clusters like Silicon Valley will you find that most programmers are in it for the joy of it, or that most programmers are particularly skilled. Outside that, it's a tool, and the people working on it largely care more about their salary than about using the tool well.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 10:36 UTC (Fri) by ortalo (subscriber, #4654) [Link]
Just a side note: would you mind me citing your above comment as an introductory note for a course I am preparing for January (computer security and embedded systems - french engineering school)?
World-writable memory on Samsung Android phones Posted Dec 17, 2012 16:33 UTC (Mon) by thyrsus (subscriber, #21004) [Link]
My first thought was: after you get root, the next thing you do is "chmod 700 /dev/exynos-mem", but reading further, it seems lots of essential functionality is linked to a shared library that depends on read/write access (via memory map). Without access to the device, I don't know how many of those are running as root already.
I knew I'd seen this before: http://memegenerator.net/instance/24372872
World-writable memory on Samsung Android phones Posted Dec 17, 2012 16:34 UTC (Mon) by nikarul (subscriber, #4462) [Link]
At last, we have the technology to write a Linux implementation of a 1980's era BASIC interpreter with proper PEEK and POKE support! :)
Why not /dev/mem? Posted Dec 17, 2012 17:07 UTC (Mon) by cesarb (subscriber, #6266) [Link]
If I understood it correctly, this does the same as /dev/mem. Then why did they create their own device instead of /dev/mem? Is it because Android's Compatibility Test Suite, which is required for calling your device an Android device, *explicitly* disallows a world-accessible /dev/mem? (See https://android.googlesource.com/platform/cts/+/master/te... for the testcase.)
Why not /dev/mem? Posted Dec 17, 2012 17:20 UTC (Mon) by andreasb (subscriber, #80258) [Link] It does what /dev/mem *used* to do. Nowadays it is restricted to address ranges that do not cover actual memory.So someone at Samsung had to copy the /dev/mem driver, remove that restriction and then, for good measure, make it world accessible by default…
Why not /dev/mem? Posted Dec 21, 2012 10:49 UTC (Fri) by ortalo (subscriber, #4654) [Link]
I would be very interested in knowing *why* he did all that. Do you think it is possible to find from available information?
Real problem: Samsung too slow Posted Dec 18, 2012 5:15 UTC (Tue) by bojan (subscriber, #14302) [Link]
Security problems happen. If they are patched relatively quickly, most of the damage is prevented. However, Samsung have a terrible record here. They still didn't patch the trivial "remote wipe" problem on millions of phones out there. How long it will take them to fix this one (which is even more serious), nobody knows.
Recommended fix Posted Dec 18, 2012 23:24 UTC (Tue) by job (guest, #670) [Link]
I take it the simple fix to recommend people is to install Cyanogenmod instead?
Recommended fix Posted Dec 19, 2012 0:25 UTC (Wed) by jimparis (subscriber, #38647) [Link]
No, because Cyanogenmod uses the same kernel. This is the patch in their tracker: http://review.cyanogenmod.org/#/c/28568/
Recommended fix Posted Dec 20, 2012 9:53 UTC (Thu) by job (guest, #670) [Link]
So Cyanogenmod has been backdoored all along, at least in all the Samsung builds? How is it possible no one noticed?
Somehow it seems like a backdoor from upstream is regarded less serious than if it originated from inside the Cyanogenmod project. I'm not so sure that is the case. All root exploits are equally serious.
I can think of a few possibilities where upstream would have interest in sabotaging downstream projects. Indeed most probably do, if you consider the locked boot loaders. If unlocked and reflashed devices are backdoored you can still reap whatever benefits locking them down gave you in the first place. And even if it is never used in nefarious ways it is still a PR win to scare people from unlocking. Stranger things have happened.
|
|||||||||||||