Threads for dmurph
-
dmurph
1 year ago
|
link
| on:
Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity
I think we ran into this when trying to fix weird corruptions of leveldb (working on IndexedDB in Chrome). Was a really annoying bug to fix - I’m sure we fullsync too much now… corrruptions are so hard to debug especially on random client machines :/
-
I really enjoyed this read - great analysis of all of the facebook calls. How crazy would it be if the authors went further and had the user also purchase domain & hosting, host the malicious website & resources themselves, making it harder to shut down.
-
-
Glad people are finding the commit() and relaxed durability functionality! I worked on both of those in chromium (well, mostly commit()) and those were the ‘easiest’ perf increases we could find.
IDB is sometimes really straightforward but sometimes really weird due to needing to be ‘smart’ about interacting with javascript.
If anyone wants to increase the perf further in chromium and has a LOT of time to kill…. I have some big refactoring projects to pitch you lol.
-
Thank you for your work on this, and sorry if I came off a bit harsh in the post. I’m sure relaxed durability and
commit()are a big improvement for cases where the page is using multiple transactions. In this Chrome bug I noticed that the benchmark naïvely usesidb-keyval‘sset()once per item insertion, probably without realizing each one gets its own transaction. I’m sure there is a lot of this pattern out there on the web, so it makes sense to optimize for it.In the spirit of trying to be more helpful and not just complain-y, I did write down some ideas for a bulk insert. I’m not sure how much of a perf win it would be though.
-
Relaxed durability also lets us use less fsyncs I think? I forget. It shouldn’t only be multi-transactional improvements, but maybe that is how it mostly shows up? I wasn’t the primary dev on this one so I don’t remember the details much.
More info about how commit speeds things up: https://docs.google.com/presentation/d/e/2PACX-1vRFevPoyBj-ntqpFmD_lRVFcBi7f1Q4fBHWR04UvLniOu_98gfgDPFo7FOv8S27ZBrqgSKexVbz5YE4/pub?start=false&loop=false&delayms=3000 (copied from my tpac presentation from a while ago) Basically it lets us skip a whole cycle of the event loop. The biggest perf hit that I found for IDB in chromium is that our current blink-side implementation double-schedules (and sometimes triple-schedules) all “responses” / “events” on the event loop. So if the event loop is super full a lot (like on page startup), then this can really delay the IDB responses reaching JS. IDBTxn.commit() helps with this (and helps on every browser, not just chromium, because all of them have to wait an extra round trip to make sure that no more IDB operations are scheduled). This double-schedule situation could definitely be refactored away to not do this, but it would probably be a quarter-long (maybe 1.5 quarter long?) eng project for someone. This is where I personally expect the biggest perf improvement potential in chromium, especially if code is waiting on idb, multiple txns are going on, etc.
We actually had an intern project for putAll - it ended up not being faster at all with our naive implementation, and ‘better’ implementations would require pretty big refactors as well?
Caveat - it’s been years since poking at this code & my memory isn’t great here lol.
-
-
-
-
Super happy someone made this! Really cool.
-
I was just talking to someone recently about how git is often designed to expose all of its weird implementation details directly, at the expense of the actual use cases being used. This seems to reflect that.
I also don’t really buy the “we shouldn’t reinforce how git trainings are teaching it”. Maybe it can more a bit more towards embracing use cases that users find useful & want?
-
I bet whoever watches Github for credentials like this makes a LOT of money. I wonder how many cloud providers they support?
-
dmurph
2 years ago
|
link
| on:
Rolling your own crypto gone wrong: A look at a .NET Branca implementation
I’m a big fan of “rolling your own crypto” and here I’m talking about implementing known algorithms.
Isn’t this article a great example of why NOT to roll your own crypto?
-
When I read the full two paragraphs around that sentence, I get the feeling it’s for educational purposes, not for real security use, which is why they encourage a security disclaimer.
I might be projecting my own views though because I think “rolling your own crypto” is a fantastic way of learning how the system works and how things can fall apart. I’ve learned how easy it is to make mistakes and I’ve never read papers and documentation more thoroughly than with cryptography and compression algorithms since both are so incredibly hard to debug. I’ve also learned a lot about tooling to mitigate these issues.
I’m a big fan of “rolling your own crypto” and here I’m talking about implementing known algorithms. I do it myself. I even think making it available on GitHub or similar, to ask for feedback, is good (if users are warned that no security can be expected).
However, a problem arises when projects that don’t even uphold the bare minimum of testing test vectors, are published with no warnings at all. Had there been used test vectors in this case, it wouldn’t have left IdentityModel completely broken.
-
When I read the full two paragraphs around that sentence, I get the feeling it’s for educational purposes, not for real security use, which is why they encourage a security disclaimer.
Yes, this is exactly what I mean. And I totally agree with your benefits, that come from exploring it for educational purposes.
-
-
Isn’t this article a great example of why NOT to roll your own crypto?
Not why. How. Avoiding most mistakes only requires following a few rules. Those rules aren’t easy to follow, but they are pretty easy to know about.
-
Exactly, I was going to post the same thing.
One reason it’s not a good idea: After showing a snippet of code that calls some XChaCha20-Poly1305 crypto functions, the author notes:
This is not a XChaCha20-Poly1305 construction.
In other words, the APIs exposed by low-level libraries are like bags of loose components. They have to be wired up correctly in order to work right, and it’s not always obvious how to do so. Even if you know about padding and nonces, a specific cipher can have its own limitations you also need to be aware of.
That’s why I’m a fan of the higher-level libraries stemming from and inspired by Daniel Bernstein’s NaCl (libSodium, Monocypher, CryptoKit, etc) which give you bigger building blocks like “cryptoBox” that do a specific thing and do it right, and choose appropriate algorithms under the hood. That makes it a lot easier to successfully implement a crypto construction, and in a way that’s compatible with other programs that use the same construction.
-
That’s why I’m a fan of the higher-level libraries stemming from and inspired by Daniel Bernstein’s NaCl (libSodium, Monocypher, CryptoKit, etc) which give you bigger building blocks like “cryptoBox” that do a specific thing and do it right, and choose appropriate algorithms under the hood.
Thanks for citing my work, appreciated. :-)
Working on Monocypher had me realise that the NaCl family ((Tweet)NaCl, Libsodium, Monocypher) is actually fairly low level. Yes, providing authenticated encryption and clean key exchange out of the box was a huge improvement. But my work on authenticated key exchange told me that high-level protocols are often fairly delicate, and require significant effort for untrained people to get them right. (Implementing an existing protocol like Noise isn’t too bad, though.) That’s in my opinion a big reason why Latacora’s Cryptographic Right Answers still recommends freaking TLS for client/server security.
I’d say the NaCl family of APIs is a good start. More work is needed to provide even higher-level facilities: full authenticated key exchange, PAKE, encrypted file formats (I’m leering at PURB), certificates… On top of those, we should then provide fully fledged network libraries, that actually handle the I/O (so far I’ve limited myself to manipulating buffers, to minimise dependencies and maximise portability). My, I’m afraid I still have a couple years of work ahead of me…
-
-
-
Multithreading usually requires a bit more programming work to distribute tasks properly, but hey, this is Tesla we’re talking about — it’s probably a piece of cake for the company.
haha hahahaha oh oh oh yeah definitely this is Tesla Motors we’re talking yeah
-
I don’t think that thread says anything about the expertise of the team that would have to implement multithreaded code, or anything about the overall level of development expertise at Tesla, really. If you’ve worked in software for a while, you should have plenty of stories like that yourself. (If you don’t, I contend you’ve been unusually lucky with your choice of employers.)
-
-
dmurph
edited
3 years ago
|
link
| on:
The bullshit I had to go through while organizing a software conference
From everything that I see on the sidelines, organizing community speakers in the tech scene seems really hard. I hear about people with really big heads, as well as people who then like to use their perceived clout to take advantage of others, professionally or otherwise. Then you’ll be getting people who have had to deal with this and are then jaded about it, and then the MRA and other trolls who will react, etc. Obviously this isn’t everyone, but yeah - seems really hard. I don’t envy organizers.
-
I’ve organized community-run software conferences (read: not paid for by any one company or consortium) with 100 to 1,700 attendees yearly or more for seven years, and other events for 150+ people yearly since 2002, save one year that I took off to focus on finishing college. I’ve had a few things go awry but nothing ever this detractive, and hopefully I never will. I (really, we) take lots of precautions and stay up to date on the news around the events community.
The thing I ask the most of everyone involved – organizers, attendees, speakers, sponsors, vendors, security guards, union convention center workers, everyone – is to be kind. You can be firm. You can be loud or quiet. It’s difficult to understand all of the moving parts that make a conference happen. It’s difficult to empathize when something seems to be on fire. Assume the best intentions. Thank someone every chance you get. Criticism should be constructive or remain factual and kind when you have no suggestion to offer. Above all else, be kind.
-
We did a mistake. We did not take enough precautions. People that worked with me knew about other issues that this people had. This year I wasn’t in the details of checking every speaker. I should have asked people if the speakers had any big issue with anybody before.
-
don’t blame yourself; any other day and in any other situation your actions would be reasonable.
-
This might be a stupid idea but have you considered re-engaging these (obviously hostile, childish) people and asking them what would satisfy them? Could there be some kind of compromise or would they only accept re-enstatment as a conference speaker and your sincere apology🙄🙄🙄?
It might be crazy to consider “giving in” like this but I wonder if maybe they might be more reasonable with face-to-face dialogue. AFAICT it’s probably harmless to try.
-
Sure, we did think about that and we are still trying to do it. I have no problem to “give in”. I only want this to stop and continue doing productive things. On the long run with the legal justice I think things will get better. In the meantime: https://twitter.com/unbalancedparen/status/1131214746731077632
-
-
-
-
-
-
Googler here, opinions are my own.
“coordinated plan that involved introducing small bugs on its sites that would only manifest for Firefox users.”
as if Googlers have time for that. I would guess simple pressure to launch fast, and not spending the eng effort optimizing for FF due to low market share.
-
-
Canvasing for Sonja Trauss, preparing for work trip, going to Autograf & Stayloose, some personal project work of sifting through group feedback.
-
That Titan chip is pretty cool.
-
Canvasing for Sonja Trauss, potting some plants, catching up on sleep.
-
dmurph
4 years ago
|
link
| on:
Chrome now strips common subdomains (e.g. www, m) from address bar display
great. one less thing that doesn’t make sense to non-tech-savy people removed from URLs.
-
Unlike the utm tracker, that they are keeping. URLs make enough sense to people, so much sense in fact that it confuses people when a URL shared doesn’t give someone else an identical view.
It is a sign of privilege and extra knowledge to look at a URL and see what, in a perfect world, might be removed.
-
-
-
Avg first meaningful paint of this person’s clients webpages is 4 seconds.
-
What a rollercoaster. First, I was concerned. Then interested. Then, I was struggling to figure out the problem. Then laughter. Then sadness.
Am I wrong here:
- Outreachy would potentially fund people to work on llvm / internships
- It doesn’t cost LLVM any money or resources to be a part of Outreachy
- No one is even participating in llvm outreachy https://www.outreachy.org/communities/cfp/llvm/
Seems rather overblown and dramatic. Maybe the drama was the point? I’m seeing a lot of ‘one-size-pie’ people. We can grow the pie! There is an infinite pie here!
-
-
disclaimer: I’m not a Mill employee, I’m just summarizing what I’ve found out from a bit of recent reading
They’re at least 1-2 years from having something that the rest of us can really mess with, outside of attempting to verify that what they’ve currently put out could work via an online compiler. Due to a change in how patents were awarded (from first to invent to first to file), the company had to shift gears from developing the CPU tech in stealth to getting patents filed on all of their relevant advances so that they stand a chance in the current market.
@angersock will probably feel a bit snarky about this post, but I’m bullish on the Mill CPU bringing something pretty revolutionary to the table. It’s just going to take 3-5+ years before we’ll see any actual fab of the chip, since the startup has been trading time for money until this past year.
I can see this potentially becoming a big deal on either servers or phones, since those are both markets where MIPS/Watt matter a lot, and where superscalars are starting to peter out. Moore’s law is slowing, though new chips are still markedly faster than tech from 5-6 years ago (as I’ve been made rather brutally aware on my aging laptop), trying different ideas like this is where we’re going to see a lot of advancement in the next 25 years, barring a change from silicon to some other computing media.
The other reason I’m bullish on Mill being realized is that the company has not been avoiding scrutiny once they had enough to show people. If a properly solid rebuttal to the arch exists, I’m not aware of it. I’ve seen a lot of people suggest that because the Mill has shades of the Itanium in it’s design that it’s likely to have a similar ill fate. Nobody has given a conclusive argument as to why, however.
What Mill Computer Inc have is rather crazy by conventional standards, but they seem to be focusing on the right problems (Tool chain, porting Linux Kernel, LLVM integration, flexible arch so they can find a niche) with the right attitude (asking for scrutiny and welcoming skeptics). They still have quite a few hurdles to overcome, but I’m excited to see just how far they’re able to take this arch. If in 15-25 years it have ends the dominance of undefined behavior and makes context switches much better, that alone would be a huge win.
-
I too hope that it works out–it’d be great to see a new and novel architecture!
I’m just a bit worried about their getting of good compiler support.
See? No snark. :)
-
-
-
https://millcomputing.com/topic/mill-computing-in-2017/
That’s the most recent I’ve seen, combined with the marked visual update.
-
-
-
-
dmurph
6 years ago
|
link
| on:
How Google obliterated my 4 year old Chrome extension featuring 24k+ users
This is how the DMCA works. Google has to take the thing down within like 24 hours or something ridiculous by law. Fuck the DMCA
-
-
-
Surely they could disable instead of destroy, then let the content creator plead a case or at least click a button, “This is a mistake”? After a few weeks it would otherwise be destroyed.
-
-
I file this under “Can be nice, but kind of depends due to C++ cumbersomeness.”
enum classinside of your class, it has to be in a namespace. This is fine, but, more things in the namespace can be a con.:shrug: