I had the idea last year to create some kind of lsp/uml chimera that would render codebases in 3D so you could navigate them wearing a vr device. You would edit files from there, create files maybe classes, draw inheritance schemes, meet with other persons, explain stuff; and that would be a somewhat fun way of welcoming interns.
Well, I could write about the rest, modular algebra, inversibility of x in mod n, why we use the product of two primes, how we are lucky to generate prime numbers, what is modular exponentiation and why it allows us to encrypt and decrypt messages, and finally, why having a public key allows you to encrypt a message but doesn't allow you to decrypt one : where does the asymetry comes from.
That's what I find interesting (not instantly intuitive).
There is something funny in the way it performs some of the moves in a sub-optimal manner. It reminds me of cats playing with small objects (earings on a beside table...).
This is still quite impressive.
Driving on the left
Speaking creole
The metric system
The 09/06/2024 date format
The Kelvin scale
The french decimal time system
The AuthaGraph projection
When setting up my DWS on the chain I performed a fresh implementation of the flex spanning system so that sharded stakes were accordingly modulated when dilution factors are on the rise. Retro validators should never rely on the sole consideration of performative liquidity, and that's why in most use-cases, distributive-non-passing underfitted categorization of assets is preferable. Every DNP-uca implementation has proto-failure systems that allow for better mining experiences, in fact every time assets are minted you obtain by-products of the initial dilution thanks to the false commitment that is produced when pseudo-stakers correct the current derivation according to the relative spike index. That's why the tech interested me at first.
Thinking about this, I observe that the problem of the factors of security is in fact tied to the problem of identifying someone : If you can prove that "someone/something" is "you", then you are giving "someone/something" the permissions to act as "you".
There are lots of tricks we invented to evade the problem; I am pretty sure our common knowledge (yours and mine) of these tricks includes the one about "knocking three time on the door in a specific rythm" or the one about "You will ask this specific question and I will answer with that exact sentence".
I would like to enquire about the problems of security and identification; cannot we do better than what we're currently doing, and why is it that any effort we do aiming for better resembles these tricks I talked about ?
What's funny about this problems is the fact that in the context of everyday life, you sometimes prove that you are you by showing e.g. an ID card to a police officer. If I had a twin, that twin could do a lot of things as me, he could do nice things, but he could also do bad things. What would stop my twin from being identified as me by others would be the fact e.g. he doesn't possess my ID card; but a card can be stolen (OTP).
My evil twin could also be suspected of not being me if for example, he didn't know something people know I know; it could also be mistaken for silliness, but okay. He could learn everything I know, or be spying on me enough so that he knows what I know (Password).
When no one doubts about you being you, it means that everyone agrees with the fact that you are yourself, i.e. every "party" identify you as yourself, and the fact that every other party is identifying you as yourself makes individual parties even more sure that you are yourself. But on what evidences rely the third parties confidence in you being you ? How can you trust that third parties aren't corrupted or mistaken ?
Take the most extreme case : you must tell if someone is lying or not about its identity AND if you're wrong, you die. I could trust third parties only if they brang some crucial facts; passwords and possession are unsignificant evidences in that context.
But if the quantity of third party is enough, and if each third party knows a different passord AND if you know a different password AND the person to identify gave the correct answer for each and everyone of them, it is becoming more and more unprobable that the person is not the one they claimed to be.
But I am not satisfied with this, there must be some more elegant and trustful way of identifying people. Now that we're able to imitate the voice, fingerprints, and etc... what other trick can we find that is not a trick ?
I have two versions of the same album, one on CD, one on vinyl. They don't sound the same and I prefer the version on vinyl, I am not implying it objectively sounds better, maybe it sounds worse at the wave level, but it sounds better to me, it seems much more "present".
Could you teach me what is the reason for this ?
Hi,
this answer feels immature and unconstructive to the discussion; I don't understand how and why you continue to treat my setup as "sub-optimal" when I described why it was that great, and you treated me as a "troll" while sourcing unrelated information. Could you please explain what is going on with you, and why you seem that upset by this discussion ?
To me, chicken sometimes tastes like garlic and herbs, while for some others, it tastes like chicken. Whenever I cook vegetables in my oven, I sometimes add garlic and herbs, people often says it tastes like chicken..
I guess meat is tasty also because it is cooked that way. Take that way of cooking, test it on vegetables, and you legit have some good recipe.
There's a ton of recipes in my country where you're supposed to cook the meat during 8 hours inside overly complex sauces involving red wine, herbs, spices, garlic, onions, salt and all that jizz-jazz; I mean, if people took that much care to vegetables, for sure they would taste good.
You only ignored my claims, and ignored the fact that your "studies" are unrelated and don't take efficient window managers into account, and ignored the fact that I was using a similar setup than yours in the past before finding this current solution, whose productivity is superior. Anecdotes do matter, unrelated studies don't. Now, I do hope microsoft will publish a study taking powerusers of i3/awesome/bspwm into account, because otherwise it seems your pride will force you into cultivating a taste for uneffective and expensive solutions, which wouldn't be a problem if you weren't at the same time showing signs of interest to the subject of what constitutes a good work tool.
I wish you the best in life.
Well, actually the informations you provided are unrelated to what is discussed here, and I shown why by the previous message.
My message are perfectly meaningful and I exposed why I think my setup is more productive and efficient than yours, and that 9 monitors are not necessary by any mean.
These studies show how people with mediocre window manager and that doesn't know how to manage their windows benefits from a second screen.
That's not my case and I am pretty sure I could show that one monitor is the fastest and most productive environment.
I am pretty sure that tiling window managers, clever keybindings that never makes you need to move from the home row, replacement of the mouse by a keyboard based solution and vimification of the desktop are faster on a single monitor, and that they are faster than normal desktop on several monitors.
Well, I honestly do such things on one monitor and I don't need more, I don't know what else to say; switching virtual desktops seamlessly is second nature and from this I fail to see the point of having multiple monitors when there is a clever approach to the problem. Shader editor, game engine, IDE, debugger, all of this can fit on a single screen, be peeked when needed to, you can layer stuff, make use of transparency, whatever you want given the appropriate window manager and keybindings server, I prefer to invest on this than on monitors as it seems a clever way to get informations from the computer. You can develop a 3d model by not looking at it when you code, because you are coding and not drawing or sculpting and because what you do is deterministic.
A software system differs from the chaos the trading world represents. You can try to evaluate traders, but the deep truth is that very good traders can become very bad traders seamlessly because nothing guarantees any success of any kind in that domain.
When interviewing software engineers you shouldn't care that much about the abilities that someone shows during the time of a technical interview on a specific day; that's not an appropriate way to measure the skills you need for your business. Leet code is an appropriate way to measure how much such engineer is able to perform as a competitive coder. You will never need a competitive coder in your team; because what to be done in SE is not about coding less than 10 lines of code in less than X minutes to transform data A into data B. But back to candidate selection, due to the short amount of time you have to meet applicants, you finally decide to hire whatever person that succeeded to find the fastest solution to the almost scholastic problem you proposed because in the end, you fail to understand what could be the appropriate selection method : aren't all candidates more or less equivalent if you stop proposing leet code problems ? What can prove that X person with 5 years of exp is less good than that one that worked at google for 6 years ? Does it really matters than candidate Y doesn't know Go when all the languages we use aren't that truly different ? Is someone from nowhere, without any education of any sort, but that seems to be an hobbyist programmer since his childhood really a bad candidate ?
You never know, but because whether you're HR or the person with technical authority in the team, you don't want to risk anything, and you believe that a good leet code solver can do the work.
And finally, to me, that's the truth : more than 50% of the persons you decided to offer an interview would have done the work with success, and at least 20% seemed very nice, and you couldn't choose so leet code was the thing.
Exactly, but having branches kind of allow you to not have to create local clones. And I legit use rsync to clone locally git repos. The question is : what is the best ?
Well, I don't even have to turn my head, <super + ]> and the screen for the web browser appears in front of my eyes.
To be fair, on my keyboard super + ] is right thumb + right index finger.
I have shortcuts for every program that I use, and every program that I use has its virtual desktop binded to some key combination on what is a very weird keyboard.
And I maintain that a small screen is perfect for redacting code (and I had a similar setup of yours in the past).
It's probably the same in other countries, but some day I did rent a field to plant some vegetables and run a small business. Every single day for one entire month I had to fill forms, sign papers, ask the field owner to give me some random information queried by some french institutions related to : nature, forest, ecology, commerce, entreprenership, business, water, rental etc..
Most of the time the field owner had to go to the "mairie" of his town to get the proper informations which would contact other services (--recursively) so I could get the information that I need to fill the forms. I am pretty sure the field owner has administration-related PTSD if he sees me again.
Shortcuts, tiling window manager and virtual desktops solves this. I noticed that I live in my IDE and then from time to time need to travel for a few seconds to something else, 95% -5%
Having more monitors doesn't make me more productive, it makes me lazier.
If I have the possibility to show a lot of lines of code, then I don't feel the necessity of caring a lot about the way my source is structured, the way my code is written and the way elements of the source are grouped.
Sometimes when I code on a 13" screen, I feel like I am more naturally inclined to write better, easily maintainable code (all subjectivity apart, I am pretty sure that better code exists objectively, not just in our cyber-tales; not just in clean code articles).
I feel like less screen implies more brain, and that more brain means the source is second nature; and because you have to compensate the lack of vision with internalization, you can projectile-find-file eyes closed and never break out of focus like when you do when you have four screen, nerdtree, lsp-symbols floating around, multiple ide panes open and having to touch your mouse just for the sake of clicking all around your squared kilometer of screen space.
That's of course an exaggeration; still I feel well more productive with small screen space exactly like I felt when I traded my mouse for a generalized vim and spacemacs-like keymap : awkward at first but cheap and effective in the end.