Well all the downstream distros have their own installers (apt, dnf, pacman, etc.). If you're compiling from source, then "make install" [0] should work as expected, and if you're downloading the pre-built binaries from GitHub [1], you just need to copy a single statically-linked binary into "/usr/local/bin".
why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?
It could have been possible to upload something like a 1.4.0+git2025mmdd package, if not for the timing of the CVE announcement with regards to Debian's release freeze.
1. buy your second game (130 DEM in 1995 / 109 EUR inflation-adjusted for 2025 / all the money you saved for weeks age-adjusted) for your new Sega Saturn.
2. notice it doesn't load on your console
3. be told that you have to send everything in to have it repaired (in retrospect find out that Saturns often had faulty CD drives)
4. wait three weeks (an eternity age-adjusted for a 12 year-old) until you get your console returned
this isn't solely about the aspect you're hinting at: plenty of smart appliances are effectively useless/inoperarive if not interacted with with their accompanying proprietary (shitty) smartphone app. Developing an alternative app requires reverse engineering; that's when you realize the current state of the art is obfuscating and encrypting each and every network layer even for gadgets as mundane as an RGB mood light.
Hacker News is the kind of place where you can have _this_ submission (PRC-sponsored Tencent-owned network devkit) on the front page next to a submission about how PRC-sponsored cybercrime group Salt Typhoon pwned 'nearly every American': https://news.ycombinator.com/item?id=45074157
3 months ago. Again, I do deep research for every company I apply for (e.g., search for employees in linkedin, check glassdoor reviews, check for potential code tasks in github, read the company/employee blogs, etc.). The research could take me several days up to a max. of one week (because more is just too much info too). I tailor (to a degree) the cv for the job (I try that at least I do have experience with 50% of what they ask, but let's say they ask for Python and I have mainly Ruby experience, well, I dedicate a week or so to brush up on Python and then I swap Ruby for Python on my cv. This doesn't work with every tech stack, of course, but works for the mainstream ones).
Another "trick" (common sense from my point of view) is to schedule if possible the first interview in the middle of the week. Typically I would schedule for a Wednesday/Thursday so that the second interview can land on the next Monday or Tuesday, that gives me at least 4-5 days to prepare for it. I try to avoid first interviews on Mondays because then it's more difficult to schedule something for the following week. I also notice that interviews with engineers scheduled in the afternoon (between 2 and 4pm) are rather "softer" than those in the mornings (I don't know why, perhaps everyone is just a bit sleepy after lunch perhaps?). I wear a white t-shirt to avoid any kind of subconscious prejudices on the side of the interviewers (you never know what kind of people are on the other side of the screen).
And many more "tricks". I know that the core of the matter is to pass the challenges, but I do care about every single detail. I write down exactly how I'm gonna introduce myself, I prepare in advance potential questions like "tell me a project you've worked recently" to the point that I feel super confident talking about them. I don't leave anything to chance, but of course I may fuck it up sometimes (and I did 4 months ago in the systems design interview).
In any case, I could easily submit my cv dozens of times, but I find that preparing exhaustively for a couple of weeks for 1 or 2 jobs works best for me (based on previous experience. I have worked for around 5 companies so far in my entire career).
> Many of the job applicant expected me to answer asinine questions like "what excited you about this role?"
I don't see this as a asinine/foolish/stupid thing to ask. It's helpful for both sides:
- potential employee can provide an honest opinion on their motivation, in a targeted, specific way to highlight their talent.
- offering company can use it for evaluating mutual fit, as well as filter out generic trash applications.
Pretty much. There is a lot to be said about silly HR questions, but this one I consider legit. And after all - if nothing excites you about changing what you are doing for 1/3 of your waking life - just be honest, say "this job is not exciting and I'm already bored and unmotivated from the start". The outcome might be not what you want, though.
It’s a pretty easy question! I always categorize my answer in a few parts - why am I excited about the product (helps people! Makes the world a better place!), the technology (I like how it is a combo of hardware and software!), and specifics from the job posting itself. Hopefully you can have a good answer otherwise why apply?
Yeah. Even without being overly candid, I don't think I'd ever have had an issue giving a fairly lucid answer to that question even if I left out the "And I need to eat part."
If there's some naive optimism in the answer, the company can take that into account in the context but may also decide the candidate is going to be disappointed or is BSing.
