Hacker News new | past | comments | ask | show | jobs | submit login
1195725856 and other mysterious numbers (chrisdown.name)
426 points by hprotagonist 8 months ago | hide | past | favorite | 78 comments



Before I click:

    $ echo 'obase=16; 1195725856' | bc | xxd -r -ps | od -cb
    0000000    G   E   T                                                    
              107 105 124 040                                                
    0000004
    $ 
Looks like HTTP.


Impressive! Before I clicked I thought this was going to be an(other) article about number theory!


printf "%x" 1195725856 will save you one bc process.


even better, thanks

  $ printf '%032x\n' 1213486160 542393671 | xxd -r -ps | xxd -g4 -c16
  00000000: 00000000 00000000 00000000 48545450  ............HTTP 
  00000010: 00000000 00000000 00000000 20544547  ............ TEG
  $


Python

  >>> 1195725856 .to_bytes(4, 'big')
  b'GET '


Maybe we should start printing ASCII in future in some of the error paths...

I work on image processing; when we get an image we don't recognize, we print out the first few bytes in hex & ascii. Often, it's an error message or HTML error page. The user's code takes the results of an HTTP fetch and sends it to us, forgetting to check for errors.


I remember fixing a bunch of bugs in 1990 because someone started running SATAN against our hosts and there mere act of sending ill-formed requests to various ports would cause the associated daemons to crash. What's amazing is that this still happens. In half a day I'll bet I could find at least a dozen super popular services that can be crashed by sending random data to one of their network ports using a default configuration.


That might be worth spending the half a day if you can get some bug bounty money for those bugs!


I still wear my SATAN tshirt monthly.

Thanks for reminding me that other folks are old, too. I hadn't heard anyone mention it in years.


>SATAN against our hosts

oh, well...

https://en.wikipedia.org/wiki/R-36_(missile)



Meanwhile, four years ago at Facebook :)

http://rachelbythebay.com/w/2016/02/21/malloc/


This is a good takeway from that page:

> I guess this means 1213486160 is going on my list of magic numbers. Also, it means that 2008-06-14 23:29:20 UTC is, in a strange sense, "HTTP time". If you see either that number or that date (with possible adjustments for your local time zone) showing up in your life inexplicably, this might just be why.


Someone owes me a steak if the thing sending GETs and HEADs (and/or fb303 calls) to any listening port on Facebook machines turns out to be procprint.

Also, we did this debugging. Years ago.


What is procprint? Googling didn't get me anything that seemed relevant, a company in Brazil and some SAS references.


It's an internal FB thing. But the post was about that, too.

(No, I don't work there... any more.)


Parent sounds like an FB engineer, so probably a tool for internal use only.


> the entire company trends towards peak levels of procrastination, doing literally anything and everything to avoid the unspeakable horror of having to write a few paragraphs of text. ;-)

the entire company trends towards peak levels of procrastination, doing literally anything and everything to avoid the unspeakable horror of having to write a few paragraphs of BS marketing speak ads for their fellow employees

there, fixed that for ya.

I hate perf! All want to say is Jill does great work, Joe does ok work. Bill might need to work on something else has he doesn't seem into it.

Instead I'm told to write several paragraphs of ad copy trying to make unique and interesting sentences that don't sound the same but basically all say the same thing "Jane does good work". They want specifics like

"Vlad's work on the ABC protocol really took things to the next level. If it had not been for his tireless effort on the ABC protocol discussion list it's likely a different spec would have been ratified and we'd all be stuck with 6 months more work in our implementation."

Now (1) I didn't actually know that because I was head down working on my own stuff so I had to go spend time 30 minutes looking that shit up and (2) That's one out of 6 paragraphs, and everyone better sound completely unique like it was meant to be presented in a magazine.

And, when it's all done it was worthless. What I wanted to write

"Vlad's great, he does good work and I like working with him"

Is all they really wanted to here but the "process" is instead a huge waste of time for everyone.


"Last week was the final week for this half’s performance review at Facebook, where we write summaries of work and impact we and our peers had over the last half year. Naturally, that can only mean one thing: the entire company trends towards peak levels of procrastination, doing literally anything and everything to avoid the unspeakable horror of having to write a few paragraphs of text."

Ugh, I can relate so strongly. Right now I'm supposed to be filling out my mid-year performance sheet, including team success goals, team player actions, effective communicator actions, achieving business results actions, business goals, personal goals, individual development plan, etc. I've been working on it for 2 days and have hardly anything done. This kind of work is so incredibly difficult for me. It is supposed to be written with maximum business jargon. I'd rather put in a week of all nighters writing some code than working on this.


Totally agree. These exercises suck because they are obvious wastes of time that are often ignored, but cannot be done frivolously as they have impact on real things sometimes.

As a manager in one particularly toxic org, you had to strike a balance where you showed constant forward motion, but not too much. Too little and you'd be tortured with meetings with a PMO, too much progress, you'd be declared a genius and the PMO would either appoint you as a "champion" to get shit done or take your people away.


It’s no more a waste to write these than it’s a waste for servers to use disk space writing out logs.


Server logs are not manually written by humans. Obviously no one is worried about the disk space. I’m ok with wasting cpu cycles writing something that might never be read but wasting humans time is just rude. [I don’t thrive in bureaucratic environments so my perspective may be skewed]


> These exercises suck because they are obvious wastes of time that are often ignored, but cannot be done frivolously as they have impact on real things sometimes.

Not really. They're ammo for whatever the manager wants to do with the target of your review. Management can spin this feedback to fit the agenda. They can also serve as a paper trail for managing someone out.


So happy I'm in a small team right now... I used to really hate doing this as an engineering manager. I had to do it for seven engineers plus submit one for my manager and one for a peer. And then I had to coach my team members on their peer reviews. And for each review you had to fill out a paragraph on seven topics some of which sounds similar. And then I have to clarify any major discrepancies between my review and two peer reviews for each engineer. And HR seems to reinvent the forms every year.


That's because they want the goals of the business to align with the goals of your team. Non-technical managers can't read software nor can they talk the talk, so this is the primary way of making sure every employee rows the same direction.


But most engineers treat it as a bullshit exercise and its hard to see how that helps anyone. Maybe we need more technical managers?


Well the result is already pre-determined, typically -- the manager knows how he's going to review the team. So yeah, it is bullshit.


I had a manager who made a standard practice of mentioning things in email in phrasing that seemed obviously intended for me to put into my performance review. It came off as pretty helpful and considerate.

Of course, the same guy fired me with no notice and no severance on the last day of the month (Wednesday), but as the termination documents helpfully pointed out, my health insurance stayed good until the end of the month.


One thing that helps me is to dictate it into some kind of speech to text system. Or just record it and transcribe later. You’ll still hate it but the content will be there at least.


That's a great idea, I'll have to try it. As a student, what helps me with similar is calling something a "zeroth draft" and just writing whatever crap comes to my mind along with my opinions on the whole process (plenty of them contain lines like "this prompt is so dumb..."). I've found once I have a few pages of crap I'm not paralyzed by where to start anymore. Plus I've never been good at outlining, so I have to write to see how to structure what I'm writing. The zeroth draft is ideally completely thrown out, but in the worst case it can be tweaked and improved and handed in if there's no time left.


I know of no studies to back this up, but based on anecdotal interactions I strongly believe that some people have an easier time writing off the cuff and others have an easier time speaking. I've known people who could speak in complex sentences but lacked the ability to write without significantly more time, and others who could write on the spot but would trip over their words when speaking. I think you and GP are describing approximately the same method of drafting, and which one works better will be highly dependant upon the individual. I don't think I'm contradicting anything you said, just adding my own thoughts.


That makes a lot of sense. I weakly believe I'm better at speaking off the cuff, but can "cheat" this by writing a stream of consciousness like how I'd talk.

A similar-ish technique for when I'm stuck trying to figure out how to phrase something: rubber duck saying it without the constraint of needing it to sound fancy/formal/academic/smart, and then remove all the "likes" and make it concise.


The headspace i get into when dictating is that I’m on the phone with someone explaining it. I can pretty easily get lost in the stream of consciousness and the resulting text definitely needs tightening up before shipping.

I think my biggest problem with writing is that i can’t get into the conversational flow and build sentences block by block. It’s exhausting.


I'm glad you've found a solution, then. For me I can get to the same headspace by deliberately writing chattily and typing out stuff like "so, like, then maybe we wanna..."


Do you type fast? I wonder if it could be as simple as i type too slow to ride the word wave.


I'm in the middle, I think.


When I still had to do these, I hated the actual experience of writing them at first, as at FB you were pretty strongly pushed to quantify _everything_. While this made some amount of sense to me, I wasn't naturally thinking of my work throughout the half in terms of how I'd quantify it. I also quickly realized the value (to my ultimate rating) of quantification in that I often my collected metrics directly referenced in my review (saving your manager time is helpful!)

I never got to the point of not strongly disliking the experience of writing reviews, but I was able to make things a lot easier for myself by regularly sharing anything quantifiable related to my work, since I could just look back at what I had shared. It also worked decently well as a forcing function, as I used the heuristic "feels like I have shared anything quantifiable in a while" for "am I sure I'm working on something valuable?"

Note that the above is purely about how I managed the actual experience of writing reviews as an IC at FB, not whether or not it's optimal. My personal opinion is probably that it's a wildly suboptimal system that's still orders of magnitude more effective than not having one at all (for me).


Do it little by little throughout the year. I keep a work log. At the end of every week I take 60 seconds or less to write down what I accomplished that week. By the time review season rolls around, I have all the content I need. No need to dread/sweat it.


This isn't for what I did in the past. It's goals/vision/etc. for the future.


Sometimes it pays to experiment a little. We had a similar annual performance reviews in an old BigCo. Everyone had to write a paragraph of text for 8-10 goals, plus an overall self-review. Then a manager had to review and provide comment for each section. I put something like "I think I did alright this year" in overall comment, and ignored other goals. Later during performance convo I saw that my manager put "Agree" as his comment, and told me that my review was easiest to do. No one really cared about that shit (with the exception of PIP).


“Maximum business jargon”? Is that autocorrect run amok? If not, what’s the rationale for it?


Business doesn't care that you upgraded to Python3. They care that you "integrated legacy software into a more performant and secure runtime environment" (or whatever; I suck at jargon).


My manager is 100% a business person. He doesn't know/understand tech jargon at all. If it isn't full of phrases like "breakthrough strategies", "proactively engage", "future possibilities", "cultivates innovation", "compelling picture of the vision", etc. (these are real examples from his template of what he wants our versions to look like) then we will be sent back to rework it until it is sufficiently obtuse.


From an actual time / money standpoint isn’t generating BS actually useless? I don’t understand the fetish so-called business people have for it. Can anyone make the business case? Why isn’t market competition culling this behavior?


I interpret it as a type of superstition - or more clinically speaking, pulling the brakes off the (mental) neural network, draping a big fat uncoordinated fog of "you're doing the right thing" over the whole thing, and letting the result iterate for a bit.

Humans seem to have a tendency to leverage complexity (adding layers until we can't see the bottom anymore) to keep ourselves engaged, so maybe superstition is a side effect of that.

And the problem is, because our brains find patterns in everything, and most readily in our own behaviors, it doesn't take too much iteration for us to go "wait, there's a pattern right there! that makes sense!!1" even when the result is comprised entirely of logical fallacies and chicken soup.


This is the best attempt at an explanation I’ve gotten in a couple decades of asking this question. Thank you


Take notes along the way.


The link above doesn’t work for me, but the following one does: https://chrisdown.name/2020/01/13/1195725856-other-mysteriou...


I had no idea anyone would find this so fast, so I thought it would be safe to change the url to match the final title before posting anywhere -- how wrong I was.

It's back now. Thanks!


Still down for me :/

EDIT: My browser cached your redirect. Opened in private and I'm OK now.


Also see this about the same topic: https://rachelbythebay.com/w/2016/10/07/magic/



good idea for the timestamps too

> I guess this means 1213486160 is going on my list of magic numbers. Also, it means that 2008-06-14 23:29:20 UTC is, in a strange sense, "HTTP time". If you see either that number or that date (with possible adjustments for your local time zone) showing up in your life inexplicably, this might just be why.



I've always been weirded out by C's 4 character constants, but they're useful for this sort of thing:

    printf("%d\n", 'GET ')
    1195725856


So his first instinct was to waste hours on this debugging instead of just googling the error message and finding the cause within seconds?


I've generally been of the Don't Reinvent the Wheel school of programming for a long time. However, I've been digging into Jonathan Blow videos again and he seems to be pretty worried lately about how little time developers spend working on fundamentals, and I agree that is either a problem, or will become one soon enough.

I haven't quite figured out how to incorporate that into my philosophy. I'm still pretty damn sure I don't want your exercise in fundamentals to be running in production, but I also don't want to be surrounded by people who only know how to look things up.


It was an interesting story. And they already established that they were trying to procrastinate.


oh wow, this is why I got these esoteric errors in my dmesg?


on the other side, i use my name as magic number (4 chars)

so both hex and dec representations got me (close numbers)

many protocols and simple ciphers use similar methods btw.


TL;DR on the annoyingly vague title: they are short ASCII strings encoded as integers.


It's a shibboleth. The joy experienced by someone who's already "in the circle" for 1195725856 justifies the vagueness. For those who aren't, the post brings them in on the joke.


“Production hosts”. “NFS traffic”. How quickly we regress.


Are you suggesting you think NFS is never suitable for production use?


Depends what you mean. If you mean "can you use it in production", sure. If you mean "should you use it in production", no, never.


Interesting comment, but for those of use who don't do infra but are curious, what is the problem with NFS, and what do you use instead? My ears always prick up when someone says ... or implies ... to not use something in production!


Start with the second answer: don't use network filesystems for production, period. To explain that you explain the first answer: network filesystems are flaky, applications and operations that depend on them often come up with weird bugs, they aren't very fast, they aren't very secure, they introduce problematic dependencies and problematic design patterns.

There are locking issues, time sync issues, permission mapping issues, there are bugs in kernel and usermode drivers, there are conflicts between clients and servers from different vendors, there are bugs in implementations of standards (and different standard versions), there are varying degrees of support, there is always an intermittent network outage that causes hard to detect bugs, you have to decide between hard and soft process locking for i/o threads, performance turning for either throughput or speed, sync or async, export security rules, encryption or no encryption (and does everything you use support it), to say nothing of dedicated or shared network gear, finding an admin to run your expensive enterprise gear implementing the server (open source nfs implementations are a joke and lack critical features), or basic maintenance like expanding storage or replication. The list goes on and on.


And yet Facebook appear to be successfully running a somewhat popular website while using NFS in production, which implies that the situation is somewhat less absolute than you claim.


Oh, you can definitely make money with a design from 2005 that uses NFS in production, 4 layers of caching, and enough servers that rebooting them constantly doesn't impact your service. I've worked at those companies. It was a bad idea then, it's a bad idea now.


That's not how it's done, and I know because I was in that group. Also, note that "production" at a company like Facebook includes a lot more than the direct web-content-serving path. I think I might agree that NFS doesn't make sense in that particular path, because it provides features and guarantees that nothing in that path needs and that means needless complexity, but there are plenty of other roles where NFS is a better fit than blob stores or copying files around.


And there's plenty of other solutions that don't have all the problems (and overhead) NFS has. There are precious few actual good reasons to use NFS and they aren't customer facing products. Particularly, when you want a rootless thin terminal on an embedded system, or read-only transfer of non-sensitive files (say, for bootstrapping a machine from bootp, or sharing a corpus of data).

For everything else (in production), NFS is a PITA, and most other networked filesystems should be avoided for similar reasons. Again: other solutions exist that provide the same functionality but do it without the inherent problems. Usually they are ignored because someone wanted to cut cost, or because legacy. Ask a storage engineer or infrastructure architect.


> Ask a storage engineer or infrastructure architect.

I've been both, and known hundreds. I'd love to hear about this solution you have that has the same functionality (your words) as a network/distributed filesystem, same compatibility, same semantic richness, same consistency, etc. without any of the tradeoffs. What are you selling?


Well to start, virtually any networked filesystem is better. Even CIFS won't hose your system from network blips, but there's also GFS2, HDFS, GPFS, OCFS, VMFS, Ceph, Lustre, Gluter, Lizard, Orange, Hammer2, MapR, Xtreem.

If you don't want to roll your own OSS solution (and I wouldn't recommend it) most modern SANs have all those features and more, available via a variety of interconnects and protocols (including shared volumes). Real replication, real snapshots, real encryption, real RBACs, and not going over the same interface as random network traffic. Storage manufacturers even offer custom drivers for K8s or VMware so you can control the persistent storage for your cloud apps directly from your orchestrator's control plane, or manage it in your SAN.


> there's also GFS2, HDFS, GPFS, OCFS, VMFS, Ceph, Lustre, Gluter, Lizard, Orange, Hammer2, MapR, Xtreem.

Until quite recently I was a maintainer for one of those. I've worked on two others. One more isn't done, two more are unmaintained, two more will trash data in specific ways I have identified to their developers, and HDFS isn't even a real filesystem. Also a couple more are proprietary. We're nowhere near "same functionality" here.

> most modern SANs have all those features and more

A SAN is not a filesystem, so it fails the "equivalent functionality" test again. No, that's not a "No True Scotsman" fallacy because you set the goalpost and it hasn't moved. If it's not mountable, not shared at file granularity, or not writable at byte granularity, it's not equivalent to NFS. You're also mixing cluster, network, and distributed filesystems in a way that makes me doubt your ability to comment cogently on their strengths and weaknesses. I developed a SAN-based filesystem at EMC, it made sense at the time (no later than 2002!), but nowadays it's utterly insane to posit that as a serious alternative. But at least now I know what you're trying to sell, so thanks I guess.


What I was trying to sell was that NFS is buggy, but past that, that it's just bad design to require the "equivalent functionality" of NFS at all. Really old applications and systems with really old designs needed NFS years ago, but now we have much better and more robust solutions for whatever janky thing a particular app is trying to accomplish with NFS-like semantics (which is really just emulating local filesystems over a network, and there's no reason a backend app needs to emulate local filesystems over a network).

If your project is greenfield, it is absolutely insane to require NFS's functionality in your design. Using NFS outside of production is okay, because when it ends up sucking, it won't sap your engineering time or budget or restrain your ability to scale. (Until non-production is a giant performance testing lab, and then NFS's suckitude does indeed restrain your business)


> Really old applications and systems with really old designs needed SANs years ago

FTFY


Is there anything that's a good idea? Or is this just "everything has bugs and issues"?


Seems like the latter. I'd guess peterwwillis has had some bad experiences with NFS. I've had some bad experience with some of the same so-called alternatives. Every time I see someone put a text blob into a database that needs to be in a file at point of use, I want to slap them. Ditto for everyone who tries to implement a hierarchical namespace on top of a flat blob store. Ditto for everyone who distributes a thousand copies of a rarely-changing file via scp or chef, then complains about update speed or inconsistency. NFS is not generally a good idea in high-volume high-node-count traffic paths, but it can be a less-bad solution in many other situations including many that are still part of production.




Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: