CorvusCrypto

While I might only need one window to code and test/run things (using command line and vim), I still have to communicate. Even if you want to use only one program, if you are on a team you still have to tab back and forth to handle communication with whatever client you use to chat/send email to each other. I'd guess even the most die hard of terminal-only programmers still have to use a second application to manage communication.

I'm guilty of printing spec sheets and physically holding them up along side my code. I haven't touched embedded systems in a while so I don't anymore, but I agree some things are best read side-by-side.

I use both. When I am in the office I have almost the same setup you describe. Code on the right on a vertical monitor and the program itself on the left. However when I am on my laptop at home it's not that bad, it's just a bit more work to tab back and forth between the terminal, editor, and program a bit more.

This argument about which is better is really silly imo. It's not like tabbing or switching focus is the main waste of time. I'd be willing to bet a lot of people arguing for either side spend more time browsing HN or Reddit than managing their workflow :V (speculation obvs)

If anyone was curious why the instruction address didn't match up, it's because he read the instruction identifier wrong. It's also totally counterintuitive and you have to essentially read the full documentation to get to any real information about it. Anyway here we go. VEX is a prefix notation with specialised encodings:

C4 - For a three-byte instruction (which vfmadd is) this is C4, if a two-byte instruction this would be C5.

E2 - This one is more involved but basically for this instruction the first three bits are 1 for setting some modes on it (R, X, and B). Then, because this is an 0f38H instruction, the next 5 bits are 00010. Altogether you get 11100010 (E2)

E9 - this is also involved, but the first bit is a W mode. This is 1 for the instruction he used but it's pretty much ignorable. for bits 2-5 it has to do with the first source register the instruction uses. This is 1101 because it uses XMM2/YMM2 (it's by lookup in a table) first. bit 6 is set to 0 if it is a 128 bit vector (it is). bit 7-8 are set to 01 based on a lookup table for the "pp" value which is 66 in the instruction identifier. Altogether that's 11101001 (E9).

A8 - this one is easy, it's the opcode.

C3 - this is the ModR/M byte which is actually used in this case for reporting the register/memory operands. first 2 bits are 11 to indicate the first operand is the register itself (not displaced, or truncated). The next 6 bytes are the register codes. 000 is actually not used since the destination is overriden for float maths), and the 011 is EBX as the base cpu register to source the data.

Altogether it works out to be C4E2E9A8C3. Not intuitive at all really.

Edit: Please someone correct me if I missed something. I hate this kind of stuff and I'm sure I made a mistake.

So then I guess my takeaway is then that there's great and poor working expectations and conditions in both areas. I found the US to be a highly negative experience and don't wish the stress on anyone. Being able to go home at night and not have to be on call or work overtime because it's expected is a great relief. I'll take that over a 100k salary any day. And certainly over my middle income job in California. However since I'm in tech I also get free choice essentially. We in this industry have it pretty lucky in that our skills are easily transferable across borders.

I am an American that found peace and happiness in Europe however because I am American you are right to say I'm biased. You don't live in a place all your life and not notice the negatives more.

While I don't feel that there is risk of brain drain because of the reasons listed in the article, I do believe there is that risk. To be honest, even though many European countries don't pay as much as the US for the same job, I found much more comfort around the ideas pushed in those countries.

The culture I found in Sweden for instance is one that is much better for the employees than the fast-paced top-gun style of programming expected in the US. Sure my peak will probably be 60k, but that 60k will also come with a much better social quality of life. That's the problem with the US that would risk brain drain in my opinion. Money attracts people, but treating them well will keep them and the US is starting to fall away from treating its workers well.

Edit: just think about this. Most Americans talk about how they have so much work to do they don't get vacation. Well in Europe you usually get your 2 weeks and in many countries you get 4 contiguous weeks without question. Couple that with better healthcare options, and yeah the US is not looking so great.

I think the bad idea stigma stems from people XORing from the same source. That totally is a bad idea, but if two sources are wholly independent, the maximum entropy in the combined systems is maintained.

To the people that just say it's never a good idea and scoff at any reasoning I'd remind them about OTPs. They are a special case related to this principle of XORing two independent sources together where only one input is random and it is proven mathematically to work.

I'm guessing they use this alongside CSPRNGs. Would make sense given the theorem that states any random number XORed with even highly-ordered input maintains its entropy.

Even if this were the case, then it's still very easy to control the market because of the authorship fees coupled with the drive toward publishing in subscription-model journals (thanks again to Impact Factor). Maybe your advisor took care of some of those costs, but most journals do have a significant fee for submission alone, not to mention the re-submission after a review requires a significant change. Sci-Hub can't change that so it still doesn't doom them.

Not to mention Elsevier, till exempel, WILL be cracking down on piracy especially after their grant from the US courts regarding Sci-Hub. Sci-hub hasn't doomed anything and the publishers still control academia. You should be mad about this, and you should blame academia itself. Push for open journals like PLoS One when possible and try to convince people to move off that god-awful Impact Factor metric and you might inflict damage on the big publishers.

How does this doom subscription journals? I mean it would be nice but realistically it just means they move to exploit the university subscriptions since the professors can't admit use of illegally obtained copies. They can further exploit the authors since many journals require payment from the author for submission and some journals charge in the hundreds. One might say "just publish to a different journal" but it's not that easy. Because of the heavy reliance on Impact Factor in scientific publishing, it is the journals with those high impact factors that the authors will try to publish to. Regardless of whether or not they are being pirated.

This is sad to say, but in reality I think this isn't going to massively impact things for the publishers. Academia at its core is where the problem lies. Sure paid subscriptions are a big part of things, but it's the stuff most don't realize (the authorship fees and institution sub fees) that give the publishers power.

This is what I remember and it was a really classic example even in Schneiers book. But yeah easy overlay method was just picking a picture with the number of pixels >= number of encrypted message bits.

Make the LSB of each pixel equal to a bit value of the message. EZPZ lemon squeezy and it doesn't affect the image visually. If your message was encrypted well then also the bits would appear randomly so no one would be able to be certain a message was contained as you said.

The infrastructure one had me chuckle a bit. Just go straight to large clusters or platform service plans guys. 2ezpz

Could just be the California style. Or finance. Don't really know any other office locales so this could be true.

You made me think of something interesting. My 4 hours NEVER happens and I'm in a cube-farm/closed space. Interruptions happen all the damn time. Sure we don't like our focus interrupted, but that's what work is. It's dealing with the managers and leads that need to ask you something urgent while managing your deadlines and dealing with noise which is still very much present in a closed-office area unless you are the board members that get to work remote.

I have one cool little experience which was an open office that switched to a closed office space during my stay. Productivity went down regardless of the boundaries put in place because now the leads and managers have their offices closed for meetings and therefore engineering staff is next in line to handle emergencies/data requests. Granted this is due to our workflow as well, however the point I'm making isn't that one setup is always better than the other but that it probably depends on multiple things and if you think you're gonna get 4 hours of golden time in a real, moving business then that's very naive or you have been very lucky yourself.

I think the reason I liked open offices is because when I needed to rethink an algorithm and analyze it I had at least 3 people that could offer their commentary. And while study groups may not work for reading a book, they damn sure work on designing algorithms when you need to openly discuss the tradeoffs and goals. Just my 0.02 on the whole thing but TL;DR sounds like open offices don't work for some places, but work great for others.

EDIT: to add to this, the open office we had was not noisey. There weren't massive conversations happening all the time and it was normally just inside voice levels of noise. I haven't experienced what I am imagining as the restaurant equivalent of an office.

>To run the game, you need to first have Generals: Zero Hour installed.

Darn, I was hoping I could clone, compile and play tonight.

A lot of vulnerabilities like this are found with fuzzing. Same with poor encryption schemes. Depends what your definition of clever is but normally fuzzing is an intermediate research step to just see what response you get as you change input to ascertain information of what's going on behind the scenes so you can use a more directed attack later.

I drive every day on the 101 and deal with the worst of the worst for >20 miles each way. I was hoping someone would mention this!

This toll plan is foolish at best and detrimental otherwise. We need incentives for car pools bad! Last count (I carpool and for fun we sometimes count cars' occupants because traffic is always a discussion) out of 46 cars we saw only 2 with multiple occupants. This is the major problem.

It is so amazing how quickly he was able to resolve this tool. 2 weeks to build a very specialized tool AND perform the optimizations on the code. What am I doing with my life?

I feel like the only person that quite liked the new header... Hm. My choices in life apparently suck.

I think the difference here is that numpy is not flaunting its speed as a benefit of using python. They are very open that they were bringing the performance of BLAS and LAPACK to python.

fosho. Will look into those, but I guess my question is if it's worth practicing some development for embedded devices in rust to switch jobs or if most are still using C and I shouldn't waste the time.

EDIT: if anyone can answer this that would be so awesome :)!

I have also been looking to get back into bare metal programming professionally (I miss the torture). Did you see an immediate switch to rust or is this a rare unicorn project in a sea of C/ASM code for embedded devices?

Idk if I share your enthusiasm, but rust is pretty cool. Certainly has its uses though for bare metal I'd still say go with C (and ASM) if using atmel's AVR chips. At least until rust gets a working compiler to AVR. Seems it is getting ever closer https://github.com/avr-rust/rust

didn't Netflix do a bunch of research into json-graph? They seemed to have figured this problem out.

I agree. Was there any thought I didn't ;)?

One thing I have noticed in this thread in general is that the web devs are extremely defensive. No, a web app is not inherently bad. No one is saying this.

But cherry picking questions to prove a point is silly. However, to show it's not a gangup on web apps here we go:

Speed of the install process? Probably slower than loading a web page for serious applications

How does the update system work? Depends if you're releasing as a single statically compiled program or using shared libs that can be updated. Also if you have a db to sync this will affect things.

How quickly can you release them to all platforms? As long as it takes to compile to all compatible targets.

Can they be easily customized and modified by the user? in what regard? if you mean configuration then yes. If you mean being able to manually tweak the style of the application like when fiddling around in the element inspector, then no unless you are using a theme parser that lets them adjust the themes.

Can they be easily shared? yes

What's the permission model like? Depends what granularity you want to have. Permissions can be restricted to the action level, user level, group level, machine level, global level, etc. Whatever logic you want to implement really.

How much can that application access? access in terms of what?

Can I just say, I cannot applaud you enough (nor other contributors to rust) for how much you care about developer opinions and ease of their introduction to the language and subsequent use! I freaking love you guys.

Cannot agree more! However, I can see the appeal of webapps. Getting started in app development using GUI APIs (cross-platform or target-native) can be a bit intimidating, too. And now we have things like electron which... well to me it's slow, but being able to develop a desktop GUI using html5 and css and JS is appealing.

And to be fair, a web app does get the job done, though I have to admit the number of companies that opt for an internal webapp instead of a desktop application is interesting.

yes. There can be a lot of boilerplate code present, however in terms of speed, using Qt for instance, can be much faster still than a web application that accomplishes the same task even if you get a huge binary after compilation.

Oh and as Nadya said, sometimes this generalization causes issues. Engineering is a game of trade-offs I think :P.

is there anything more you can say about your buffer solution? Curious if it is something similar to vector clock syncing that you guys came up with.