> He had always been good at math, so he put together a formula—a proprietary algorithm that he loves talking about but declines to explain in detail, saying only that it “measures the supply of cattle every day and determines that if we buy a certain percentage of cattle, we have a seventy percent chance of winning.”
There’s a whole other science to cattle pricing so hard to tell what he’s hinting at. Cattle are priced using either cash pricing, or grid pricing, or formula pricing. Sounds like he working formula pricing to his advantage
True you can write readable Perl code, but developers tend to adopt the predominant style of the community of each language, and the community was showcasing more brevity and cleverness than clarity
Perl rose to popularity because early web development was all about text processing (reading web forms and outputting HTML) and Perl made that easier (regex deluxe) than other choices on unix at the time. It became the lingua franca of web developers. Perl 5 made heavy use of symbols so it was visually noisy, and then Perl 6 came along and added even more magic meanings to other symbols, and that was a tipping point of perl’s decline. Readability of code is paramount. Code is for machines to execute and for humans to understand. Perl code became both modernist abstract art, and Baroque in its intricacies.
Nice. Reminds me of longtime security tactic for web servers of shipping logs and mounting the entire file system as read-only so that intruders have no means of installing their root kit.
> “trust in institutions controlled by humans and bound by established laws and rules is instead replaced — by unconditional trust in the infallibility of code“
No, it’s not just trust in code, you’re also trusting the people that wrote the crypto coin client apps and operate the crypto exchanges. Sketchy crypto apps and exchanges already have made off with clients’ coins. That’s not a blockchain vulnerability, rather that’s a vulnerability in every market where you transact through brokers - you’re implicitly trusting your brokers.
A Blockchain is just a linked list of records with accumulative crypto signatures, which gives a you a crypto-verifiable indelible ledger. To make it a trusted financial ledger you just need to have trust in everyone involved between the finance clients and the ledger.
I was well into high school before I realized that many supposed many class bullies teased everyone, and especially their friends. From their perspective they often meant their teasing to be playful rather than hateful, but recipients of teasing could take it either way.
Metaverse is what VRML tech was aspiring to back then, but standard dial-up internet, early web browsers, and PCs could not deliver immersive realtime 3D. It was obviously decades ahead of its time. I recall needing to install web browser plugin (I tried a few), then the VRML scene file takes a while to download (dial-up) and then draws an ugly 3D scene in the browser. Then the mouse navigation was horrible. No collision detection of course so you could easily fly through the floor, end up upside down, walk through objects, etc. No sound. No chat. No multi-user. At least it had level of detail optimization so processing wasn't on distant details. Then you'd click on a link in the scene and it would either load a different 3D scene, or jump you back out to a plain old 2D web page in the web browser. And of course you'd be looking at this on a plain old 17-inch CRT screen (no VR headset). I see my Oculus collecting dust and I feel VR tech has improved by a lot, but still, meh.
Love it! The sordid truths of data science laid bare! "We prefer subtitles over machine-learning-based detection because the presence of a cough in subtitles means it was prominent enough for a person to write it down. Also our postdoctoral fellow was the only one who completed the Tensorflow tutorial."
Whenever I stumble into a political conversation with someone who prefers to live in an alternate news reality, I find it effective to not argue back at them, but rather out-flank them: inform them that not only are they correct, but also I read that insert-like-minded-improvised-obviously-ridiculous-nonsense-here and say it with all sincerity ... and then let them respond with "Well ... I'm not sure about that ..." and then insist it's true "because I saw it on Faceboook somewhere" ... and then repeat until they realize they have been out-crazied.
Engrave it on stone in three different languages, use OCR to import it. If it must be digital media then store as plain ascii text files stored on multiple types of media. Plain text remains the only consistent digital media format over time. Digital archeologists will likely have jpeg rendering tools in their toolkit as well.
I’m not sure I agree because the advice from the article was mostly “grow the ops org” with a bit of push some ops responsibility back to dev teams, rather than seeing the ops org growth leads to further dependence on ops to get things done.
“Innovation teams shouldn’t be burdened with operational concerns” Surprising how prevalent this attitude still is. It leads to large Centralized ops teams are inevitably going to be a bottleneck. If developers need to routinely create tickets with some other team to do get their work done then clearly the org is heading the wrong way. the org needs to invest in more self-service automation and ops training the developers with a mindset of reducing the size and responsibilities of their ops team rather than just hiring more ops which makes the problem worse.
Good point. MongoDB scales horizontally (add more servers) PostgreSQL scales vertically (get a bigger server) which is the least desirable way to scale, in addition to be being reliant on fewer servers makes it less fault tolerant. MongoDB is also schema-less which is convenient for developers and makes change management easier , but the cost is your app has an undocumented and unrestricted data model that only your core devs can partially explain, and your business analysts absolutely hate anything that isn’t standard SQL. So the story with MongoDB is core app devs still love it, operations is OK with it, and for everyone else you better copy that biz data into something that speaks standard SQL or the analysts will riot.
These are the wild west days of crypto finance. Fortunes will be made and lost. There’s hype, fads, bubbles, and spectacular blowouts. The crypto finance tech ecosystem will evolve, consolidate, then eventually be diluted and homogenized into standard investment frameworks, and tamed by onerous oversight and regulations. In the meantime, if you can’t resist the urge to place a bet then don’t bet more than you can afford to lose without regret.
Whole situation sounds like typical startup growing pains and this is the OPs first rodeo of this kind. The original crew of developers was happy during the early days when it was all cozy and limitless upside, but now there's new funding, new bosses, new managers, new processes, new rules, new coworkers that "don't get it" and that old fun and cozy vibe is lost. The new CEO will likely be fired by the board too, but face it, the cozy days are over. So either find yourself a role in that circus that you like, or quit.
First of all, Tokio is my favorite async framework, so thank you and the Tokio team! And second, I appreciate that cargo/rustc compiler errors are clear, helpful, and guide me toward cleaner and thread-safe coding where most other languages happily let me create unsafe hidden race bugs all day long with no warning … oh but they compile so much faster! (I don’t care) The slower compile time really doesn’t bother me when I’m getting a more stable end result… but I’m glad the maintainers are working on improving compile time anyway.
To me the extra compile time makes sense when rust is showing me many unsafe coding issues that languages seem to ignore even with their strict warnings enabled.
… and I don’t get all of the complaining about rust. I’ve written code in a lot of languages and rust has its quirks too, as they all do, but I really like it!
top and free also double count memory footprint of common shared library’s across many processes that are using the same “.so” library. Use pmap to see how much unique memory each process is actually using vs. shared libraries.
I dabbled with Atari 2600 game programming. I can appreciate how the frugality of the VCS design put really tight constraints on game devs and in hindsight the VCS could’ve been worlds better if a bit more was invested in hardware. As a game dev on VCS, the kernel of your game loop is essentially drawing each horizontal scanline (on a CRT screen) in realtime, so you have a budget of about 20 assembly instructions (during the hblank at the start of each scan line) to describe what gets drawn on that line as it’s being drawn, including players and missles, and playfield. Then between each frame (during the vblank and overscan) you have a budget of about 30 assembly op codes to detect collisions, change the playfield graphics, adjust the sound, check paddle/joystick inputs, etc. It’s a crazy tight clock cycle budget to work with. I honestly struggled with writing a simple game that could use so few machine op codes per frame, I couldn’t stay in budget so my frames were a mess. I wonder what could’ve been if Atari invested a bit more in giving developers a little bit more to work with. Nintendo NES came out soon after and seemed to learn from Ataris mistakes with the VCS.
The graphics (and sound) was much lower res, smaller worlds, fewer characters, less motion poses per character, prebaked character frames, the floors and ceilings were flat, the textures had far fewer colors, the lighting and shadows were prebaked onto static surfaces, game code was performance tuned at the assembly code level, symmetrical textures, low contrast textures … and we all needed to pay for 2MB more RAM to play Doom.
This. Version pinning is just piling on the risk, and when a CVE is announced on the no-longer-supported version you’ve been pinned to for way too long then it’ll be a reactive emergency.
Needless Paragraph (ads) filler paragraph (ads) filler paragraph (ads) filler paragraph … I gave up. This should not have been upvoted. We ought not reward content this obnoxious.
AES-256 cipher is already quantum safe (Shores Algorithm does not apply to AES-256) but the quantum achilles heal of TLS communications is the asymmetric key exchange (often RSA or Elliptic Curve) that establishes the shared key used by the AES-256 payload encryption side of TLS. The concern is that any TLS handshake and data traffic recorded today could be later decrypted offline when quantum computers catch up. Lengthening the RSA key size kicks the can down the road, but ultimately TLS cipher suites will need to add a quantum safe suite of key exchange algorithms.