-
The thought of facebook ads subtly appearing in an immersive VR experience is rather unsettling.
-
I highly doubt that Facebook’s acquisition goal is solely another way to deliver when it’s been made clear by most involved that the opportunity with VR goes far beyond merely games, or social applications.
-
Except Zuck said so, to Time Magazine.
Facebook does not yet have a business model for Oculus, but revenues won’t center around selling Oculus Rift headsets. Zuckerberg said he could envision people visiting virtual worlds where they can buy goods and are served advertisements.
-
-
-
sdoowpilihp
4 years ago
|
link
| on:
Syncthing replaces Dropbox and BitTorrent Sync with something open, trustworthy and decentralized.
Looking through the protocol, I can’t tell if when you have edited a file, it sends the whole file again, or just the blocks that contain the delta. The latter would be huge in regards to performance.
-
-
The more I mull over the concept of bitcoin, and how it’s playing out, the more I see dangerous and harmful patterns emerging from within it. Things like unbound computational costs for mining that are strongly correlated with a coins fiat value; That 99% of the world has already been priced out of the bitcoin market (most people can not afford to spend $500 on a coin); And that single individuals within the market are now in control of majority shares of the total available coin, only begins to scratch the surface of what is wrong with bitcoin.
-
Lots of marketing speak.
How does IOS security compare to other phone OS’s? Other hardware platforms? Is it best of breed?
Can we do better in the future?
Anyone care to comment?
-
I’m surprised you’re so quick to dismiss this as marketing speak. That the 5s doesn’t stores fingerprints, but something akin to a hash of the fingerprint, is something worth knowing. The section on Data Protection APIs available to apps is also fairly technical.
What information is missing that you think is needed to make this a technical document?
-
You’re right. My comment might be a bit too trollish.
I think, in general, I am put off by all the “fluffy sentences.”
The introduction might have put me off with it’s talk of “major leap forward” and “stringent security features.” So, I didn’t read everything.
But more examples of fluff:
Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient
“Highly efficient” isn’t exactly technical. Efficient in time or space or power? I think they were talking about power. How much more efficient, then? Why are they even talking about efficiency, when the topic is security?
But my questions in the grand parent stand: Is IOS more secure than other platforms like Android? That topic of conversation was really the point of my post.
-
“Highly Efficient” may be an approximation, but it certainly isn’t non-technical. It is also used in a lot of technical papers:
http://scholar.google.com/scholar?hl=en&q=highly+efficient&btnG=&as_sdt=1%2C5&as_sdtp=
In regards to whether or not iOS is more secure than Android, that is a massive, and likely very difficult to quantify answer.
-
“Highly efficient” is not technical, in my opinion, because it’s not backed up with any facts (and doesn’t pertain to the topic of security). I think it’s just fluff.
In the google search you posted, for example, on the first result I looked at the article and they explain what they mean by highly efficient:
lipofection is from 5- to greater than 100-fold more effective than either the calcium phosphate or the DEAE-dextran transfection technique.
-
I think we may be playing semantics. Regardless, I do agree that it would have been nice to have a far more granular analysis of the various components that make iOS “secure”.
-
-
-
-
Why are they even talking about efficiency, when the topic is security?
People don’t use inefficient crypto. They are pointing out that they can easily, transparently encrypt all the data on the phone, as opposed to selectively only encrypting the very most important bits.
Why doesn’t every computer always encrypt everything on the hard drive? Because people are afraid it’s too slow.
As another point that’s not mentioned in the paper (likely beyond the scope), the ios kernel is perhaps better hardened against memory corruption exploits than any other I’m aware of.
-
Another reply. :)
Securely erasing saved keys is just as important as generating them. It’s especially challenging to do so on flash storage, where wear-leveling might mean multiple copies of data need to be erased. To address this issue, iOS devices include a feature dedicated to secure data erasure called Effaceable Storage.
That’s something I’m happy to read and which I didn’t know when I woke up this morning. When I erase my phone and mail it to Amazon, I like knowing that the data on the phone is not trivially recoverable with some undelete command. That’s not fluff to me.
I alluded to ios kernel hardening. For some of the things Apple doesn’t talk about, refer to this presentation.
-
-
-
Here is some analysis comparing android to ios, based on the original article (I think).
-
-
This week I will be finishing up the first version of the Dylan mode for CodeMirror [ http://codemirror.net/ ]. After that, I will focus on wrapping up my Redis library for Dylan [ https://github.com/pvwoods/dylan-redis ] so that I can start using it as a back end for experimenting with Open Dylan’s HTTP library.
So much Dylan.
-
O man, totally looking forward to Dylan mode for CodeMirror.
I’d love if someone got to adding the missing documentation to the HTTP library before me ;)
-
-
“For prospective candidates, three hours might seem like a lot of time for an initial “interview”, but in reality, it saves time for everyone.”
I may be a bit jaded here, but it seems that this tactic saves time mostly for the employer who no longer has to sift through the ‘chaff’, and makes the interviewee assume a large portion of the risk up front. As a potential candidate, I would find this worrying, and barring anything else that made the company truly stand out, I wouldn’t bother with the test. I am sure it is not the interviewers intent, but the technique comes across as being in bad faith.
Also, for anyone with responsibilities (deadlines, teams to manage, children, etc), a “24 hour window” to work on a 3+ hour project is going to be a bit unrealistic.
-
Thanks for the feedback. Regarding the 24 hour window, so far most of the candidates we’ve interviewed are in college or recent graduates. We’d definitely consider expanding the window for anyone who has a more demanding schedule. Our intent is to be more flexible than phone interviews by allowing someone to work around their schedule, instead of setting a specific time block.
And we’d definitely hop on the phone with a candidate to tell them more about Sourcegraph up front. All the people who’ve done the challenge so far we met previously at a job fair or through a mutual contact. The post doesn’t do a good job of mentioning this, but we’re definitely not saying, “Here, before we even talk to you, you must do this 3 hour task.”
I hope I can convince you that this experiment is not in bad faith. Having gone through a bjillion of these ourselves and sunk many hours into interviews that didn’t pan out, we wanted to try to make things better for all parties involved.
-
-
Stuff like this makes me really unhappy:
1.1 + 1.01
2.1100000000000003
Especially when I want some kind of versatile way to display that information according to units. Money, uptime, etc.
-
-
-
If you divide integers without thinking, you won’t get good results either. 3 / 2 == 1.
Real world quantities are rarely infinitely divisible. You always have to think about the remainder and where it goes, regardless of the representation your computer uses to perform the calculation.
Trivial example: 3 roommates split the $1000 rent. If they each pay $333.33, they’ll come up a penny short. Whatever process the roommates use to decide who pays the extra penny, you have to add that code to your rent splitting computer program. It’s not going to happen by magic.
The problem is not floating point, per se; it’s omitting the large part of the process that deals with edge cases when translating the real world into a program.
-
The problem is not floating point, per se
That’s not my point. The grandparent post said:
Always work in cents, seconds
In js, if you pretend to try to use int’s you get:
<script> var cents = 100; var splitBetweenThreePeople = 3; var split = cents/splitBetweenThreePeople; alert( split); // 33.333333336 </script>So working in “cents, seconds, etc” fails. It just fails differently than you expect if you’re expecting JS to be using integer math.
-
Buggy code is going to be buggy. A better exercise is to try writing correct code. The correct version of the above isn’t too difficult. Then compare that to writing the same code but using an amount of 1.00 dollars.
Working in cents doesn’t automatically make the code correct, but at least it allows you to write correct code.
-
-
Calculate the split and remainder, then distribute the remainder afterwards.
cents = 100 splits = 3 share = Math.floor(cents / splits) remainder = cents % splits for (i = 0; i < splits; i++) people[i] = share while (remainder--) people[remainder]++This will give you people = [ 34, 33, 33 ].
Trying to do this with dollars is impossible because you can’t store either 0.33 or 0.34 in a float. The best split that can be accurately represented would be 0.25, 0.25, and 0.50. (You could come close by allowing fractional pennies. 0.3125, 0.3125, 0.375 add up to exactly 1.00, but you still have the problem that nobody has fractional pennies and rounding after the fact is extremely error prone.)
-
-
-
-
-
-
-
when you need a perfectly accurate representation, with a known level of precision (like money, or uptime), fixed point numbers (or at least some take on the concept, a la twips) would be your best bet.
-
-
sdoowpilihp
4 years ago
|
link
| on:
Dropbox's hiring practices explain its disappointing lack of female employees
Is there empirical data that clearly demonstrates the correlation between “Super Power” related interview questions favoring candidates of one gender? I very much want to see the industry go through a correction in regards to the gender split, but I doubt this quasi scientific article is helping the effort.
Also, is there a specific reason that DropBox was singled out regarding this relatively common interviewing tactic?
-
I think Dropbox was singled out because it has so few women on its engineering team. That’s probably not exactly fair though, since an engineering team of 143 is still relatively small so it’s bound to be skewed. I once worked at a startup around the same size and I can only remember one woman on the engineering team (although there were a few technically-trained women on support).
But more importantly, is this interviewing tactic relatively common? I’ve interviewed at several large tech companies and a few startups, and I was never asked any questions like the ones mentioned in this article.
-
Why is a small team “bound to be skewed”?
-
Probability. Flip a coin a few times. The percentage of times heads comes up after 10 tosses will probably be much farther away from 50% than after 1000 tosses. There is a lot more variation when the sample size is small.
Also, I’m not sure where they got the “18% of the hiring pool are women” number from. I guess they were going by the percentage of female CS grads. But consider that not everyone who graduates with a CS degree wants to be a software engineer.
-
-
I have been asked similar questions once or twice. The prevalence of those types of questions in your standard interview may be over stated though.
-
-
-
This is weird. A transaction isn’t quite identified by its transaction ID, but only by its contents. So somebody can replay your transaction simply by giving it a different number, and then hoping to win the race.
I think it’s reasonable to consider this a protocol flaw, and it’s something I didn’t know about, but how can mt. gox proclaim ignorance when people in the know have been talking about it for 3 years? Shouldn’t mt. gox be in the know, too?
This is also another case where I’m confused how a bitcoin operator can even have the problem they’re having. I’m not the world’s greatest accountant, but I’m also not running a money service. When a bad customer performs the above trick and claims the transaction failed, why doesn’t mt. gox check the account balance (blockchain) and see that the money has in fact been transferred? mt. gox should know how much money is in their wallet, right? They can compare the amount they have now, the amount they had an hour ago, and the total of transfers they believe occurred.
-
-
It seems that the recommendation by the core developers is essentially duck typing the transaction. I imagine that though this would work for low frequency transactions (maybe less than 1 every few days), the lack of a definitive way to identify a transaction will become a serious issue in high frequency transactions between a small number of addresses.
-
-
Interesting tool, bad name.
-
What specifically do you not like about the name?
-
-
-
I wonder if it would have made more sense to generalize the use of the yield command to allow it to be used outside of the “return and pause” concept within only the scope of a function. I imagine a world with a lot less boilerplate code if I could simply write:
var user = yield SQLDB.execute('select * from user where id = 1;");Then again, this may introduce some serious design challenges.
-
While I cannot attend a meetup in the Bay Area, I must insist you meet up at a Red Lobster.
-
Cheddar biscuits for everyone!
-
-
I was very surprised to find out there was not a good open source alternative to meetup.com, so I will be working on a basic implementation of that this week.
-
So… why Comic Sans? Is security supposed to be funny? I would have hoped that OpenBSD wouldn’t be so flippant about a clearly serious issue with a major component of modern computer security.
I donated to OpenSSL, but I definitely won’t be donating to these folks. Maybe when they decide to not be so sophomoric about this, I will change my mind.
So for years, months, weeks, people have been saying “Somebody needs to clean up OpenSSL. Somebody else, of course, but definitely not me.”
Now somebody is cleaning it up and all anyone wants to talk about is “ZOMG they use CVS”. And the web site font.
Consider the current design of the web site to be a kind of litmus test. Is the font used the most important criteria when you go to pick an SSL implementation? If you could pose one question to each SSL implementation, would “Why Comic Sans?” be that question?
It wasn’t the font in and of itself, but rather the overall attitude of the people developing this project (you can also view commit logs that take digs at former developer’s work). Maybe I am in the wrong, and it shouldn’t matter, but I tend to not respond well to the attitude that is taking place with this project. There’s a lot of smack talk taking place, and it’s probably unnecessary.
Maybe it’s different in the open source world, but I wouldn’t want that kind of ethos on my dev team.
So at the risk of being berated, I’m going to stand behind the decisions made by “the developers” who took on the task, and gave of their time to fix openssl. First, the folks who wrote openssl, however cordial and fluffy and pleasant they were on mailing lists and irc, did an absolutely abysmal job of writing software. This wasn’t just some piece of junk, inconsequential, resume booster on github. This was a library that was being used and trusted by enough people on the internet that the consequences from vulnerabilities and holes are likely to affect a solid, measurable portion of services on the internet. Most consumers have no idea how bad this software is… that is until a hole so big, so potentially devastating that upwards of 40% of internet sites needed to invest time emergency patching things.
The people who wrote openssl do not deserve to be complimented, well respected, or given the benefit of the doubt. Trust me when I say that the people who have taken time to dig into the former openssl code tested out the severity of things before they published information (Ted’s blog for instance). They understand what a mess it is because they’re in the trenches reading the code. Being “sophomoric” about things has been earned. It’s been earned by the people who have given their time, spent hours, days, weeks, reading code and fixing it, regression testing, sending out diffs, and making sure thousands of ports and packages still work. It’s been earned by the people who originally released this pathetic excuse for a cryptography library. Commit messages are harsh and we cry about it? Have you been on the internet lately? Have you read hacker news? If you’d honestly spent time in the code, if you honestly understood how terrible the current state of openssl truly is/was you wouldn’t be berating the people who are trying to improve software that much of the internet relies on.
We only care about CVS v. something else because we have to rely on a Tumblr to get hilarious commit messages, and, as you know from working with me in ye distant past, I for one most definitely pick my projects based on commit message hilarity.
See, that’s why you need to be subscribed to source-changes or you miss out on a lot of the other good stuff. I’ve managed to get about half the dialog from Conan the barbarian into commits deleting files unrelated to OpenSSL.
I am imagining this:
I’m not sure why people confuse “humorless” with “taking things seriously”.
“This software was written by programmers that wear suits and don’t smile. We might not write good code, but we take things oh so very seriously.”