Hacker Newsnew | past | comments | ask | show | jobs | submit | brenainn's commentslogin

My 64gb DDR5 kit started having stability issues running XMP a few weeks out of warranty. I bought it two years ago. Looked into replacing it and the same kit is now double the price. Bumping the voltage a bit and having better cooling gets it through memtest thankfully. The fun of building your own computer is pretty much gone for me these days.


>No one "deserves" free time.

I do! So does everyone I like.


A good time to point out https://github.com/Hypfer/Valetudo.

I haven't tried it personally because my particular model of vacuum has some complicated and potentially destructive procedure to get the required access, but there's quite a few models where it can be installed easily.


I am super happy with Valetudo.

Since the robots got cameras and microphones, it's a no-go for me to have it in my home connected to some cloud.

It's little bit challenging to orient oneself in the project (tip: read a couple of the last release notes), but once you do, it's great.

I bought a new robot vacuum that was specifically recommended by the Valetudo project (Dreame L10s Pro Ultra Heat). The rooting was straightforward and non-destructive. The robot works great.

And the usage is much better even for non-developer people (i.e. my wife), as the UI is simple, not constantly changing under your hands, no ads, no upseling. It's a tool as it should be.


> ... because my particular model of vacuum has some complicated and potentially destructive procedure to get the required access

This right there is the root of the entire problem. We had IBM PC clones that you could recover and keep running for decades by easily replacing expansion cards, HDDs, RAM sticks, peripherals and even circuit components like caps, ICs and batteries. We used to partition our 50 GB HDD into a dozen little partitions and multiboot every conceivable OS out there. Now we have an oligarchic dystopia where even RAMs and batteries are soldered on and bonded with single-use resins instead of age-old screws. Even if you get through, you can't salvage or swap ICs because they're paired individually at device level. You can't reach the boot partition without a Ph.D in RevEng and a risk of still bricking the device 3 out of 4 times. And that's all for technological progress and security, they say! Those claims have as much credibility as their claims to making an honest living. It's weasel-speak, not engineering insight.

Modifying the device that you paid for should never be this complicated. Those greedy corpos are usurping the consumer's rights and wealth, plain and simple.



From my understanding (I might be wrong) the images are pre-built by the owner of the project right? I remember there being a form you fill and you receive a download link.

If that's the case what guarantees do I have there's no "funny business" on the image?


It runs entirely on LAN, ie; you just go to the vacuums IP address in a browser to control it. So you can block internet access for it if you're worried with no negative effects.


You can then cut the robot off the internet completely.

Which you cant do with the 1st party apps. This alone is enough for me.

The private builder is not great, but the reason are understandable, it is what it is.


I have it on two of my Roborocks and it rocks.


I had my own reply, but using your analogy if I may: if I asked an apprentice carpenter to measure up and build some sort of structure in front of me with the tools provided, and they stumbled and made some awkward choices but the result was otherwise sound and they had other good qualities, yeah I'd consider hiring them. I think the scenario you describe though would be more equivalent to someone who flat out doesn't know how to even use a computer, which is a different case (I wouldn't hire that person).


I was thinking about basic tool use. I expect a junior engineer candidate to wield a computer way better than my mom. They are applying for a junior engineer position not and apprenticeship starting with close to zero training. I have no problem with candidates who stumble and make awkward choices during the interview, as juniors by definition lack experience and the interview process is a stressed situation.


I think we need to stop seeing "can program" as being equivalent to "is an expert computer user", because those are genuinely two different, if related and overlapping, skillsets.

There is no particular reason that an expert C++ programmer also needs to know every keyboard shortcut or be an expert at the Linux command line, if those things are not actually relevant to the job you're trying to hire them for. Just because it's been common among millennial and older programmers (like most of us) to combine the two doesn't mean we should discriminate against programmers who don't fit that mold, as long as they're actually good programmers.


You're presenting a false dichotomy, though. No one in this subthread is expecting an expert computer user. We're just expecting them to have their development environment already set up, and to be familiar and comfortable with their tools.

If they come in with a Linux laptop but aren't comfortable with the command line, that's weird. If they come in with a Mac or Windows laptop and do solid work only with GUI tools, that's fine. If the job requires being able to use specific tools (command-line or GUI or whatever), then the interview should evaluate that as well.


Then, among 200 resumes, how do you find the good programmer? If you have budget to hire one of them.


Well, first of all, most likely dozens of them, at least, are good programmers.

In fact, most likely dozens of them will be perfectly good hires for the position.

The idea that you must hire only the single best possible candidate can lead to some pretty dehumanizing treatment of applicants, when the truth is that a) there almost certainly is no "single best possible candidate", there are many people who would do a roughly equally good job there, and b) your processes are almost certainly not optimized to actually find the true single best candidate for the job, but rather the person who is best at applying and interviewing for jobs among the candidates.

All that said, for "how do you actually design a better process"...I sure as hell don't know. I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.


> I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.

No, it pretty much does mean that.

Until you can come up with concrete improvements and understand the potential flaws in those proposals as well, you can't usefully critique the existing system.


Can only a master chef tell you that your chicken is undercooked?

Can only a trained programmer tell you that it's a bug when you press the "OK" button, but your program does the "cancel" action?

Can only someone who knows exactly how to build and fix a system tell you that a specific aspect of the system is flawed?


Better example: you press the ok button, and sometimes, only sometimes, it triggers twice.

You tell your lead, they say "I know." You ask why they haven't fixed it, and they lead you down a deep rabbit hole of fundamental, unsolved issues with event bubbling, and show you the 20 different workarounds they've tried over the years. "In the end," they say, "nobody's figured out how to not get it to sometimes fire twice."

Thus hiring. Sure it looks not right to you, but, come join us in hiring and you'll see, a better way has yet to be found. At least when I run interviews it's an actual real problem rather than a leetcode thing - I always just grab something reasonably difficult I recently did for the company and convert it to an interview problem.

Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain. Of that 10, 2 were the best. Criticizing not wanting to work with the best doesn't make sense to me. Lemme put my capitalism hat on, there: we have competitors, we need to code faster than them to get clients before them. If we don't, we lose revenue and don't get another funding round, and the company dies. Also all hiring is reported back to the investors who have an expectation we get good people. Also we give equity - why wouldn't I want the best possible people on my team so that I have the highest chance of my equity paying out big?

Capitalism hat off, yup, this system is dehumanizing and not configured to deliver the greatest societal good. Alienated labor detached from the true value of the goods produced, absolutely. What can I do about that at my job? On the side I run a co-op that operates under literally the opposite principles: anyone can join, we will train you to get the skills you need to get better jobs, and no margin of the rate is siphoned away for a capitalist class.


The problem with your last paragraph, of course, is that there is no "system", no generalizable concept of "societal good", no such thing as "true value" independent of the subjective evaluations of an object by disparate parties, and no "capitalist class" that actually exists as such.

Everything is down to particular patterns of interaction among particular people, all acting on their own a priori motivations, with none of the reified abstractions you're referencing actually existing as causal agents.

I applaud your efforts with the co-op you're describing, and if you're able to make it work, scale up, and sustain itself in the long run, more power to you. But it's a bit strange to imply that in the more common scenario, it's somehow untoward for the people paying the upfront costs of your endeavors -- and indemnifying your risk exposure -- to expect a share of the proceeds in return.


> Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain.

I mean, this is fundamentally dependent on the specific position being hired for.


I'm interested in this conversation however this comment doesn't really mean anything to me. What are you saying? And so, how would you hire? If you just wanted to say, "hiring sucks," I agree. Hiring sucks.


This comment is saying "the percentage of any given 200 programmers applying for a job that are, in the end, reasonably fit to do the job depends on the job being applied for".

If the job is a mid-level C++ programmer job at an insurance company, many more of them are likely to be good fits than if it's a senior embedded systems architect job at an aerospace firm.


I think going by that, for juniors anyway, isn't great. Remotely coding during an interview isn't a great environment to start with, and you're probably seeing a lot of people unable to achieve any sort of flow because their mental capacity is devoted to the interview. Some people also won't pick up more advanced tooling until they have to start coding day after day for a living, and until they have other people to learn from. That was my situation anyway.


I like lit. I'm not primarily a web developer and I've found it intuitive and easy to read and write. What I find more confusing than frameworks is building, bundling, ES modules, the whole NPM ecosystem.


>building, bundling, ES modules, the whole NPM ecosystem.

That's evolved hand in hand with the React monoculture over the past 10-15 years, maybe by way of a project called Babel.

Babel set out to provide progressive enhancement for the original ES5 to ES6 migration, and then in classic POSIWID fashion began to thrive on a suite of a la carte incompatibilities.

That experience is as much a contributor to the current automatism to to reach for (non-configurable) Prettier and Eslint, or more, than any rogue devs imposing fell coding styles.

So yeah, plenty of things in JS infra that look like they've been designed to be a pain in the ass (a.k.a. "behavioral nudge", towards TS, what else) and very much seem like the result of more inept moat-building in the then-newly ballooning field of frontend dev.

Readers might look up whan an import map is sometime, as well as where it is and isn't supported. How TS handled ES modules at the time Node16 changed their ESM support. Does ESM `default` correspond to CJS `module` or `module.exports`? Room for vendors to fuck up in innovative ways all round, this whole rotten ecosystem.

Readers are also advised to try Deno if they haven't yet. On Node, try Vite instead of Webpack. Most importantly, try Lit with JS, import map, no builder/bundler, and test suite with coverage. Work out what is most comfortable for you, work out exactly how much toolchain makes you the most productive, and afterwards don't forget to ask yourself why the React cultists want to stick everyone in a hairshirt if not a straitjacket.


I got more of a LinkedIn vibe. "I am good at sex, here's my take on Eastern philosophy".


In your experience, what have you seen that works?


Me too! Amazing that he's still alive.


Yes but ...

"In 1996, Bugorski applied unsuccessfully for disability status to receive free epilepsy medication. Bugorski showed interest in making himself available for study to Western researchers but could not afford to leave Protvino."

This is just sad all around through and through.


Not to excuse it, but Protvino in the 90's was...kind of a shitshow. The early 90's were a little like post-war UK - think food stamps, standing in line all morning just to buy your measly weekly meat allotment, most city services on the brink of failure. Many of the chronically sick or disabled, or injured veterans, ended up basically being kicked to the curb when they no longer had the social safety net that (however low or high quality) they had in the USSR.

It took heroic efforts to leave to the west in those times. The best most people could swing was finding work in Moscow or Serpuhov and commuting there on the daily. And this is all considering that it was a 'science town'; Many of those who lived there in some way worked at or adjacent to the accelerator institute and were fairly well educated individuals.


As someone that's bought their first house in the last few years, it's hard not to take offense.

A car or a TV are much smaller investments relative to a house. Over a decade of savings is tied up in my home. If the ass drops out of the market, myself, and others like me, who have broken into the market without assistance at the peak of housing prices will be virtually permanently financially set back. And to call buying a house around this time a mistake is crazy. I would be as much a speculator if I continued to rent and pay someone else's mortgage, hoping that prices dropped so I could get a good deal. It's a home and this attitude of treating homes as investments or mere purchases is why we're in this mess in the first place.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: