It's not only that the CVE database / process is broken, but via EO 14028 in the U.S. and CRA in Europe transparency is mandated via SBOMs. While I believe this transparency is good, it can be abused to enforce compliance-driven security: Fix all critical, high and medium CVEs within well defined time frames. PCI DSS and many other standards kind of encourage that view already today. It will then just be measurable by outside parties, which then means the limited security budget will be used to "fix" things that don't matter as much.
And I agree with you, Lars: We should be using CISA's KEV, First's EPSS and other means. But I'm not sure software customers would accept seemingly higher risk (high number of unfixed critical / high CVEs), even if the EPSS suggests overall much lower risk.
I've written in longer form at [1] about this issue.
Adobe | Product Security Engineer | San Jose or Remote USA | $129k-$235k salary + RSUs + Bonus
Are you interested in creating Security As Code content that has the potential to reach thousands of developers? We are hiring for a product security engineer that is familiar with writing custom rules for an automated code review platform that includes Static Application Security Testing (SAST) and Software Composition Analysis (SCA) scanners. If you enjoy creating developer delight while also helping to increase the overall Securability of Adobe products you might be a great fit for our team.
The idea with multi-cycle memory was to create a special challenge for myself. Also I thought about using the same technique would be useful if I later on wanted to have mul / div in hardware, which would take a couple of cycles too.
I'm watching this video about TL-Verilog, and the part starting here shows how powerful it is for that kind of thing: https://youtu.be/hQ6HhOBHKy0?t=2048
In short, you can define generic reusable flow constructs like stall and backpressure pipelines. You can then instantiate them and slot in your logic, and signals will be automatically pulled through the different stages and pipelines as needed. The example at this part of the video shows then how adding something can be a two line change when it would be hundreds of lines if you were working at the RTL level: https://youtu.be/hQ6HhOBHKy0?t=2581
I'll think about sharing the code. Large code parts - while working - did not pass my quality bar, since I did not have enough time to clean and refactor while learning. But maybe that's fine. Hmm.
Your goal wasn't to write a C++ or Python app it's was to create almost everything from first principles. I also don't think anyone would doubt your abilities after reading this post. You could link to the article in the repo. I think it's speaks for itself. My first thought when I read the article was "Wow, this is great." I've read it twice now. Thank you for sharing.
I always wanted to understand how a CPU works, how it transitions from one instruction to the next and makes a computer work. So I thought: let's implement one and run a C program on it.
The textbooks by Hennessy and Patterson are the definitive ones. I think every programmer would be very well served reading them. There's older editions available online for free that are perfectly adequate for understanding the big picture.
To be fair, all the wires he uses are pre-cut / pre-shaped for the video. The videos are meticulously planned and marvelously executed. Normally hobby projects do not have nearly as much thought put into them.
I've been taking the time to perfectly measure out all the wires on my 8-bit because I don't mind the monotony, its kind of peaceful. But holy hell it takes a long time.
Its like 95% measuring and cutting, 5% thinking, testing and debugging.
Its a bit of a welcome relief from software, which is 95% thinking and 5% typing. A bit of monotony might be good for the brain.
It's got a very slow, methodical onramp with a lot of diagrams and a light, breezy style. You end up building a (very simple) computer in the end, including instruction processing.
I have an econophysics degree, work in IT and can easily compete with CS graduates. Started my first job as a software developer and now I'm the head of my own development team and also responsible for hiring.
As a physicist you are a problem solver: You will learn how to learn, how to tackle complex challenges in a systematic way and analyze experiments. These skills are very useful. If your physics and math knowledge helps you later on depends on your future job. My own work does not involve physics, nor any non-trivial math.
The biggest hurdle will be getting your first job in IT: You have to show that you are as capable as a CS graduate. That's easier if you apply for jobs that don't focus on algorithms, for example systems programming. Though some companies will only hire CS graduates and miss the chance to get cross-domain knowledge...
So how to show the hiring manager that you are good at writing software? Write (open source) software, mention projects on your CV and also in your cover letter. I love to see links to github / bitbucket on a CV.
If you have passion for writing software, are willing to invest a huge amount of time and you know how to teach yourself then you can be become a great software developer.
gateProtect is a company providing security solutions focused on unified threat management (all-in-one firewalls).
Backend Software Engineer: Help us write the control application of a network security device using Clojure. You are an excellent software developer and know many different paradigms from object oriented to functional and used your knowledge to create complex systems in many different languages like C++, Haskell or a Lisp dialect. Prior knowledge of Clojure is not required if you know another Lisp dialect. You also know the details of low lewel systems programming under Linux.
Backend Software Test Engineer: Write automated tests that check if the production code is working using Python. A strong understanding of network protocols, related tools and Linux is more important than excellent programming skills.
Please contact job@gateprotect.de for more details and mention Hacker News.
And I agree with you, Lars: We should be using CISA's KEV, First's EPSS and other means. But I'm not sure software customers would accept seemingly higher risk (high number of unfixed critical / high CVEs), even if the EPSS suggests overall much lower risk.
I've written in longer form at [1] about this issue.
[1] https://florian.noeding.com/2023/08/29/sofware-bill-of-mater...