FWIW - last stage where the binary is produced takes the longest and is single threaded and that's the largest difference between release and debug.
518 karma · joined February 24, 2014
FWIW - last stage where the binary is produced takes the longest and is single threaded and that's the largest difference between release and debug.
```
> cargo clean && time cargo build
cargo build 713.80s user 91.57s system 706% cpu 1:53.97 total
> cargo clean && time cargo build --release
cargo build --release 1619.53s user 142.65s system 354% cpu 8:17.05 total
```
this is without incremental compilation. And it's not like you have to babysit a release build if you have a CI/CD system
I get the sentiment though, "He blew management's mind so much they made an exception for him".
But, Folklore.org is a bit less onanistic than ESR's jargon file.
For what it's worth, here's quicksort in 5 lines of haskell https://stackoverflow.com/questions/7717691/why-is-the-minim...
1 - GNU utilities is ancient crufty #IFDEF'd C that's been in maintenance mode for decades. You want code to handle quirks of Tru64 and Ultrix? You got it.
2 - Waving your hands around 'the community will take care of it' is magical thinking. C developers don't grow on trees. C tooling is kinda weird and doesn't resemble anything modern - good luck finding enough VOLUNTEER C developers to make your goals happen.
In OSS every hour of volunteer time is precious Manna from heaven, flavored with unicorn tears. So any way to remove Toil and introduce automation is gold.
Rust's strict compiler and an appropriate test suite guarantees a level of correctness far beyond C. There's less onus on the reviewer to ensure everything still works as expected when reviewing a pull request.
It's a win-win situation.
Three of my direct coworkers died from covid. One guy didn't get his sense of taste back for a year.
People just gasping to death in their bedrooms waiting for things to improve and only going to the overloaded ER when it's too late.
I'm an asthmatic, I've been close to that feeling where sub 90% oxygen saturation made me feel like death. Anything like 80% your lungs start to fail. You're dead in a hurry.
You do all this upfront design about how it's going to work and then "Oh god there's so many splinters and sharp corners, it's only getting worse and every new team onboarded to the framework needs to have their hands held, and management won't allocate time to address the tech debt."
Also the subtle flex of making the Donkey Kong girders on an angle when the 2600 is a 'race the beam' system where each scanline must be computed. Even modern homebrew remakes of Donkey Kong on 2600 have horizontal girders.
So - I'm guessing game logic of MECC Oregon was in Basic with some assembly routines to re-draw the screen. BTW original Oregon Trail was also 100% basic and a PITA to read. You're really getting to the edges of what applesoft basic is practically capable of with games like Akalabeth and Oregon
Or is it "You fool! Building your own kitbashed Gundam of an OS is the point."
"We're looking for someone with experience with ASP and database performance improvements."
"You mean, ASP.net - not old school VB6 derived, interpreted - 'pretty cool for 1997' Active Server Pages - ASP?"
"Hey hey! You're the guy we want!"
Of course I would have taken the job if I'd known they'd be acquired.
edit: Huh, they were acquired in 2014? Ah well - it's like someone's MVP that made it out to production, then they made it big and that MVP kept being glommed onto.
8 year old me knew there was something different about the comic art alongside the text, yet I couldn't explain what. Turns out - British!
The machine code books would have been useful at that time, but again, I'm 8 playing with a hand-me-down Apple with no other help. I don't know what I don't know and I have no mentorship and no internet or bbs access to download new stuff.
Kids today have access to all the video tutorials they could ever want.
e: God DAMN line numbers suck. And double god damn do line editors (think ed as opposed to vim) with no proper backspace.
That's the problem of building something super-cutting-edge on a grand scale - you run the risk of making a super evolved version of an evolutionary dead end.
Sure it sounds like a cool idea at the time, the Cell optimized SETI At Home demo around the PS3 launch ripped through work units far more quickly than any Intel system.
I wonder what became of the cluster once it was decommissioned? Military surplus PS3s anyone?
9000 cycles/s / 1.79 MHz = 0.5% of realtime. The only time you ever see rendering a line at a time is single stepping through an emulator.
I wonder if this is how FPGA developers working in VHDL/Verilog see the world? https://www.patreon.com/posts/37038491 here's a short clip of the VRAM of a PSX rendering about half of a completed frame of Final Fantasy 7's battle screen.
Oh yeah - microsoft's time travelling debugger is under appreciated, even with their quality tooling. But, it's on the windows platform. So anything like this on Linux sounds like a very positive step forward.
It's like you're more in love with the Idea of the FSF than the FSF as it stands today, reflexively self-protecting its old guard and completely inhibited by the my-way-or-the-high-way attitude of RMS.
https://en.wikipedia.org/wiki/List_of_Sega_arcade_system_boa...
the 2000's and on is just console hardware with upclocked CPU/GPUs and more RAM, or outright x86 + Nvidia Windows PCs running some sort of Windows embedded.
Compare this to the Hyper, and it's a MIPS cpu with custom ASICs. A completely dedicated system that doesn't have any amortization in games for the home market. The last of an era.