> Young devs won't believe it
Sure they would. They believe anything. I made up some nonsense one day that bytes weren't always 8 bits and they believed that shit.
12-bit words enter the chat
Readit NewsYoung devs won't believe it, but in the late 1990s, quite a number of software companies didn’t use source control at all. You just copied source files from/to a central location, and from time to time made a version_x.y.z copy of the source directory.
My first job in 2012 was still working this way....
I always get cynical when I see awards for software releases. Someone always gets an award for staying up late to fix a last minute problem. Normally the person that should have written good code in the first place so they wouldn't have had to come in late. The award should go to the person (likely people) who never got called in at all in the first place because we didn't find a bug in their code.
You guys get awards?
diamondo25 commented on Pyobd - a free and open source program for car diagnostics github.com/barracuda-fsh/... · Posted by u/madviper
Newb question, can I use this to change something in the configuration of the car? I have parking sensors that are absolute garbage (overtriggering all the time), and I would like to permanently turn them off. The turn off button works only for a moment.
No, that would involve coding, and that is vendor specific. You can look for your car manufacturers diagnostic tools, eg mercedes star diag, or vagcom.
diamondo25 commented on Show HN: Gogit – Just enough Git (in Go) to push itself to GitHub benhoyt.com/writings/gogi... · Posted by u/benhoyt
I always respected the fact that the authors of Subversion, right from the start, structured their software as a library, with the CLI being a user of that library.
The way IDEs and GUIs interacted with CVS was to shell out to the CLI, which inevitably had problems with filenames with spaces, parsing of error messages, etc. Subversion understood in 2000 that the things were changing, and that the CLI was only one way you'd use a VCS. People were more and more interacting with the VCS via IDEs, or via right-click menus in Windows Explorer, etc.
I felt happy knowing I'd never again have to deal VCSs via tools just shelling out to their CLI ever again. How wrong I was...
JetBrains forgot this memo, as it requires you to configure svn.exe in order for it to work. And usually TortoiseSVN is the way to go for subversion...
diamondo25 commented on The six dumbest ideas in computer security (2005) ranum.com/security/comput... · Posted by u/sweenycod
A reminder that a big part of the subtext of this piece is a reactionary movement against vulnerability research that Ranum was at the vanguard of. Along with Schneier, Ranum spent a lot of energy railing against people who found and exploited vulnerabilities (as you can see from items #2, #3, and #4). It hasn't aged well.
I'm not sure there's anything true on this list that is, in 2023, interesting; maybe you could argue they were in 2005.
The irony is, Ranum went on to work at Tenable, which is itself a firm that violates most of these tenets.
I've read about 80% of this page, and eventually stopped at the part where he says that the next generation will be more cautious. This, in my opinion, is false. Most software has simplified for user experience, and has not helped kids in the slightest bit. Its more addictive than ever, and all caution gets thrown out of the window when we let kids browse youtube unsupervised. Heck, a wrong search query or random text can give you NSFW content. And with the rise of shorts/stories/tiktoks you'll be molded by the algorithms. You don't or have barely any control over the content you see. If it notices you watch, what, 5 seconds? of a clip, it'll start recommending that.
The issues we have nowadays are different than those in 2005. People that havent seen the bad parts of the internet, will not teach their kids about it either...
Strange claim, because Hertz's fleets are comprised of new and almost brand new vehicles, which usually only require oil changes.
Then they sell them off after accumulating 10,000-25,000 miles, before any real maintenance is required.
20,000 miles is what, 4-6 oil changes?
I think the main issue is how people drive these cars. If you have a lot of short trips, or overrevving, or just in general abusing it (because rental), is much more common on ICE cars compared to electric ones?
diamondo25 commented on Ask HN: What's a build vs. buy decision that you got wrong? · Posted by u/kiernanmcgowan
A C# redis lib. For just the basic set/setex/del/exist and an auth layer and proper retry logic both the StackExchange and the (try-than-buy with command limit!) Other popular lib, I just made my single-file driver instead. I didnt need clustering and async. Much better and something I can trust, as well as much less code, so less error prone.
The point I attempted to make was that elixir and your caching needs are orthogonal.
However, to indulge Go vs Elixir in this context (note it was two different systems, companies, and scale referenced above): Elixir has the amazing Ecto query builder and I think poor schema design along with good tooling let folks be productive and build a couple of years of cruft into a tangled knot of table dependencies and access patterns and materialized views.
Go tends to eschew ORM like things and I believe some pressure on the devs to think more about the actual queries being (hand) generated would have exposed schema inefficiencies earlier (instead of Ecto automagically pulling all the data you need, you see the heavy lifting when writing the queries).
And to your point, with a fucked schema and or access patterns, Go vs Elixir or any other language is a moot point. Cheers!
Of course you can use an ORM with Golang, and will have reduced throughput. However, I wonder how much you can profile for both languages and fix the bottlenecks by rewriting things. It can also depend on the machine and how the VM allocates the threads and memory allocation (for example multi chiplet, multi rambank support).
- Try to get stuff tested earlier (see point 1)
- if things can get be tested, write tests while working on the code
- split a feature up in chunks and develop parts
- take your time. Pressure of failing sprints (whatever that might actually be caused by) does not help. Smaller changes help with getting others to respect your time too. Everyone is happy when stuff works :), even if its incomplete