Piero Bosio Social Web Site Personale

Rules* Never execute scripts from the internet* Never execute scripts as root if you do not know what they do#Programming #bash #sh #csh #ksh #fish #OpenSource #fork #bomb #forkbomb https://www.cyberciti.biz/faq/understanding-bash-fork-bomb/

@arclight Thanks for the insight.

Quick question: I've seen a lot of programming gifs (screen-recorded gifs of terminals). Which tool(s) are used to create those?#programming #terminal #gifs

@Dendrobatus_Azureus @mirabilos has been doing a great work for a long time, here

OpenBSD v7.8 is released in the world!#OpenBSD #BSD #Unix #OpenSource #POSIX #Programming https://www.openbsd.org/78.html

@G3rt capito grazie.

Then: The Internet is designed to route around failure. Now: The Internet is five companies and one of them is broken. #aws #programming #networking

#programming

cross-posted from: https://lemmy.dbzer0.com/post/55628224 I’ve been thinking about discovering underappreciated Lemmy instances. GitHub’s awesome-lemmy-instances used to serve a similar purpose, but it hasn’t been updated in a long time, and I haven’t found anything else like it. I got the idea from this post about finding decentralized communities in the Fediverse. I’m thinking of a Lemmy bot that tracks Lemmy instances, calculates the average number of active users and standard deviation, and identifies instances with activity below the average plus two standard deviations. It would then rank these underutilized instances by performance metrics like uptime and response time, and periodically update a curated list on Lemmy to guide users toward instances that could use more participation. I'd love feedback on how you would go about doing something like this. And specifically how to rank by performance.

@rperezrosario I assumed programmer+fediverse=Linux, because that's my feed. But, also, over the three+decades I've been working in tech, I've seen more and more devs being Linux first devs, to the point where the company I work for now has been almost entirely Linux users among the dev team. I don't keep close tabs on everyone, but when it comes up, it's more Linux than anything else, with MacOS second. Everything cloud and web is Linux native, so it's all easier on Linux.

@stefano @nixCraft @imil Here on Debian {in MX Linux} I had to add the following tools since the machine is not configured for programmingbmake`apt install bmake`bsdtar`apt install libarchive-tools`then success>> log# $ ./startnb.sh -f etc/sshd.conf* using console: vioconusing QEMU version 7.2.19 (Debian 1:7.2+dfsg-7+deb12u16)[ 1.0000000] NetBSD 11.99.3 (MICROVM) Notice: this software is protected by copyright[ 1.0000000] Detecting hardware... (QBOOT 000000000000)[ 1.0257426] done.[ 1.0345973] kernel boot time: 51msCreated tmpfs /dev (1835008 byte, 3552 inodes)add net default: gateway 10.0.2.2Starting sshd.Server listening on :: port 22.Server listening on 0.0.0.0 port 22.>> End of log^ZI pressed ^C to enter the server to add the needed passwords for the user and rootlogin was a success then#netBSD #BSD #UNIX #OpenSource #programming #quemu #bash #sh

The software that takes one developer 30 days to create, cannot be developed by 30 developers in 1 day. #mythicalmanmonth #programming

@andre123 😊🙏🙏🙏

@codeDude64Who's that girl?Nice thumb area!

I've been only able to read this IT note today due to band with constraints. It read like a Stephen King short. Horrific!IMHO, In my humble opinion, the company involved used tactics that I can describe as blatantly criminal.I have some stories and I may talk about one in another post, using similar of obfuscation techniquesYou would be wise to read this story at least twice.Read between the lines.Observe that the company was selling open source services yet used criminal tactics to keep people locked inLinkhttps://it-notes.dragas.net/2025/10/08/the-email-they-shouldnt-have-read/#Story #Stefano #horrible #ethics #unethical #OpenSource #programming #vendor #lockin

@etam Good ones.

Yeah ok so my experiment was successful, and my toy raytracer now runs on JIT-compiled "shaders" lmao#programming #rust #raytracing #retro

spdlog 1.16 released #programming https://github.com/gabime/spdlog/releases/tag/v1.16.0

Summary of A Philosophy of Software Design by John Ousterhout Source: danlebrero.com These are notes by Daniel Lebrero Berna on John Ousterhout’s A Philosophy of Software Design. Some advice in the book goes against the current software dogma. The current dogma is the result of previous pains, but has now been taken to the extreme, causing new pains. What the author solves with “Comment-First Development,” others solve with Test-Driven Development. The excuses for not writing comments mirror those for not writing tests. Key Insights It’s easier to see design problems in someone else’s code than your own. Total complexity = Σ(complexity of part × time spent on that part). Goal of good design: make the system obvious. Complexity accumulates incrementally, making it hard to remove. Adopt a “zero tolerance” philosophy. Better modules: interface much simpler than implementation (Deep modules). Design modules around required knowledge, not task order. Adjacent layers with similar abstractions are a red flag. Prioritize simple interfaces over simple implementations. Each method should do one thing and do it completely. Long methods are fine if the signature is simple and the code easy to read. Difficulty naming a method may indicate unclear design. Comments should add precision or intuition. If you aren’t improving the design when changing code, you’re probably making it worse. Comments belong in the code, not commit logs. Poor designers spend most of their time chasing bugs in brittle code. Preface The most fundamental problem in computer science is problem decomposition. The book is an opinion piece. The goal: reduce complexity. 1. Introduction (It’s All About Complexity) Fight complexity by simplifying and encapsulating it in modules. Software design is never finished. Design flaws are easier to see in others’ code. 2. The Nature of Complexity Complexity = what makes code hard to understand or modify. Total complexity depends on time spent in each part. Complexity is more obvious to readers than writers. Symptoms: change amplification, cognitive load, unknown unknowns. Causes: dependencies, obscurity. Complexity accumulates incrementally; remove it aggressively. 3. Working Code Isn’t Enough Distinguish tactical (short-term) from strategic (long-term) programming. The “tactical tornado” writes lots of code fast but increases complexity. 4. Modules Should Be Deep A module = interface + implementation. Deep modules have simple interfaces, complex implementations. Interface = what clients must know (formal + informal). Avoid “classitis”: too many small classes increase system complexity. Interfaces should make the common case simple. 5. Information Hiding (and Leakage) Information hiding is key to deep modules. Avoid temporal decomposition (ordering-based design). Larger classes can improve information hiding. 6. General-Purpose Modules Are Deeper Make modules somewhat general-purpose. Implementation fits current needs; interface supports future reuse. Questions to balance generality: What is the simplest interface covering current needs? How many times will it be used? Is the API simple for current use? If not, it’s too general. 7. Different Layer, Different Abstraction Adjacent layers with similar abstractions are a red flag. Pass-through methods and variables add no value. Fix pass-throughs by grouping related data or using shared/context objects. 8. Pull Complexity Downwards Prefer simple interfaces over simple implementations. Push complexity into lower layers. Avoid configuration parameters; compute reasonable defaults automatically. 9. Better Together or Better Apart? Combine elements when they: Share information. Are used together. Overlap conceptually. Simplify interfaces or eliminate duplication. Developers often split methods too much. Methods can be long if they are cohesive and clear. Red flag: one component requires understanding another’s implementation. 10. Define Errors Out of Existence Exception handling increases complexity. Reduce exception points by: Designing APIs that eliminate exceptional cases. Handling exceptions at low levels. Aggregating exceptions into a common type. Crashing when appropriate. 11. Design It Twice Explore at least two radically different designs before choosing. 12. Why Write Comments? The Four Excuses Writing comments improves design and can be enjoyable. Excuses: “Good code is self-documenting.” False. “No time to write comments.” It’s an investment. “Comments get outdated.” Update them. “Comments are worthless.” Learn to write better ones. 13. Comments Should Describe Things That Aren’t Obvious Comments should add precision and intuition. Document both interface and implementation. 14. Choosing Names Names should be precise and consistent. If naming is hard, the design likely isn’t clean. 15. Write the Comment First Like TDD, comment-first helps design, pacing, and clarity. 16. Modifying Existing Code Always improve design when changing code. Comments belong in code, not commit logs. 17. Consistency Don’t “improve” existing conventions without strong reason. 19. Software Trends Agile and TDD often promote tactical programming. 20. Designing for Performance Simpler code tends to be faster. Design around the critical path. 21. Conclusion Poor designers spend their time debugging brittle systems.

Fixing some stuff & adding reflections to my raytracer (along with capping nested traces at a maximum number of bounces)#programming #rust #raytracing #retro