janosdebugs

That then becomes a hiring problem as that's limiting it to one geographic area. If it falls out of favor in 5 or 10 years, it's really hard to move the company. I've seen effective remote teams, but it requires a high degree of independence from everyone. Typically, it's also much harder for people early in their careers.

The companies mandating RTO seem to be in the few thousand employees and up range. My experience is that at those sizes a developer spends most of their time figuring out what and how to code, which is mostly done in meetings. Writing code in such a setup is a relatively small part of the work. Developer effectiveness doesn't have that large of an impact on their success, whereas organizational skills and leadership do.

I believe, most of the companies that we hear instituting an RTO mandate have distributed teams, so that in-person interaction wouldn't manifest in these cases. Also, I live in a country with very meaningful transportation infrastructure, I still wouldn't want to spend 1.5-2 hours every day crammed into said infrastructure at rush hour for no good reason. Buying a car would have saved me 30 minutes tops and I find it irresponsible when public transport is available.

Thankfully, I no longer work for a company that mandates in-office work and even the telco (!) I used to work for had unlimited home office even before the pandemic, which worked beautifully and saved them lots of money.

Having an office to go to helps the more socially inclined employees, but doesn't boost productivity uniformly, especially when everyone is on calls all day anyway.

Just like home office, full in-office work needs a very special setup to be truly effective and given global hiring, may be harder to achieve that a remote culture.

Does this not present a security problem due to being on the same domain as the godev.com login system?

From what I know, this wouldn't work. I worked for a telco and the way they explained it to me is that SIMs for these purposes are not the same as consumer SIMs. They end up on a different network using a different APN and they typically go straight to a VPN or other private network for their owner. And no, you can't reconfigure them to the consumer APN (I asked). (This was not in the US btw.)

If the wrong people are hired, they will spend 5 days a week drinking coffee, attending meetings that generate more meetings to seem super busy, and generally slacking off.

Does SR-IOV actually work in practice on consumer grade cards these days? Apart from WSL, I haven't done virtualization in a while.

I am not an expert in statistics, but i have read quite a few papers in my area (IT/Kubernetes/etc) that had an obviously faulty methodology if you have experience at all. Reading the other comments, this software should have never been used in this manner, which it seems to me someone who is hopefully well-versed in this area should have caught. Then again, the reviewers may have had very little experience in this area. (This happened to me, when the review came back the reviewers admitted themselves in the form that this was the case.)

This sounds like the person wasn't a particularly good developer either. Bugs not withstanding, part of the job description for a good developer is having communication skills.

Huh? Safari exists for Windows? Isn't that like a super old version?

I wish most of the software I use wouldn't need access to a GPU. Unfortunately, the only thing keeping me on Windows right now are graphics-related things (Adobe and friends).

No, the question is: how did peer review not catch it? I have the impression that reviewers don't have the time or incentive to give papers more that a cursory review. Independent of this case, a great many papers are published where the only "proof" is a user study or survey with an extremely low number of participants, but it still gets published. Many papers don't publish their datasets and don't contain enough detail to try and replicate their results.

There should be a real incentive/compensation for reviewing properly and real consequences if a paper gets retracted for reasons that should have been caught in review.

In this case it's fortunate that it did get found out in the end.

This kind of thinking is sadly lost on many. I have seen copious amounts of nonsensical tests slapped full of hard-wired mocks and any change in the functionality would break hundreds of tests. In such a scenario an LLM might be the bandaid many are looking for. Then again, the value of such tests is questionable.

Doesn't Windows ship OpenSSH these days?

As someone who writes a fair number of docs, I would not want AI-generated wordsalad in them. AI is usually way too verbose and not to the point to be helpful. It also makes a lot of mistakes on technical products. Then again, compared to not having docs at all this may be preferable.

So, like Selenium but without the coding?

At your scale you may just want to give it to them for free or not take the customer. It's unlikely they will come after you for this amount I'd say, but if you grow bigger I can imagine this coming back to haunt you. I also don't know if you'd be subject to UAE commercial law if you take a customer from there, there are some jurisdictional norms in place you may have to explicitly disclaim in your terms of service. You can get sued internationally and that gets really expensive.

Talk to a lawyer, talk to a tax attorney. Don't take legal advice from the Internet since your situation is likely not going to match the person's who answers.

That is true, but your lawsuit with the client is a contract dispute. The client can sue you for damages that you caused, which may far exceed what they owe you.

Transport is one of the easiest to substitute with alternative means in many parts of the world. Then you don't have the CO2 from manufacturing the car (electric or not) and you don't produce any while traveling. My family and I decided to get rid of the car 3 years ago and we didn't look back. We are fortunate enough to live in an area with acceptable public transport and we got ourselves bikes as a supplement. We ended up renting a car 2 times in 3 years, one of which was a moving van. Won't work for people living in remote areas, but it's doable for many.

We have also not used a plane in the last 4 years, but that's something many won't be willing or able to do.

It's at least worth thinking about if nothing else.

I don't own a Vision Pro, but according to the reports you need to actively look at UI elements to interact with them. In other words, you'd end up only using your peripheral vision for driving. Unless a special driving mode is implemented where you only use passthrough (at which point just take it off please) I don't see this being safe. What does this thing possibly get you while driving that you can't get otherwise in a much safer way?

I really hope that sudo is going to allow one to capture the output of the thing running in sudo and handle errors better. I recently wrote an installer script in PowerShell and had to go through severe contortions to support privilege elevations for only a minimal part of the script. I needed to use start with runas to relaunch the same script with different options to continue the installation process and there's not much in the way of proper error handling either.

Because someone working on something on the side will be much less efficient than someone working full time. If that certain someone is contributing good stuff, you want to make sure their incentives are aligned with your interests.

Git LFS would like a word.

I taught a coding bootcamp (one of the early ones in 2010-11) and I've met several people out of bootcamps. You are probably looking at several years of seriously hard learning and putting up with a significant setback in your career with very little in the way of using your existing skills. I would rather try to learn coding myself and move over gradually if I were you. You are not going to be anywhere near an expert in coding after one year if you start from scratch.

We only have one petri dish planet close by. No control, and the experiment takes a very long time.

From the articles I read on this in German and this one it seems to me that there is an easy to miss point: the consultant didn't have any authorization from Modern Solutions to conduct a pentest, he was working for a Modern Solutions customer. When he discovered the hard-coded password, he should have stopped there and reported it.

Not at all, but we are talking on a submission about getting open source work paid. I've done my fair share of unpaid open source work and it was a ton of fun. I've had a lot of very good experiences with the community coming together to resolve an issue, but I've also had bad experiences, mostly with larger entities consuming said projects and not willing to contribute in any way, shape, or form.

With that premise, recently I've experienced more and more release engineering asks popping up around open source: SBOMs or other compliance reports, regular dependency updates (dependabot and friends), regular releases, support cycles, supplying a DEB/RPM/APK repos, shipping on Snap, Homebrew, Winget, Chocolatey and who knows where, sign with cosign, GPG, x509 and so on. You get the picture. I have yet to meet an engineer who likes to do release engineering in their free time. It's hard to test, it's hard to automate and is super sensitive because if you mess it up you leak keys or compromise user systems.

This is something I believe the poster needs to address, otherwise their platform will be full of projects doing feature-driven development with important safety and maintenance concerns left by the wayside. Although I have seen a few working models, I don't know the solution for all of open source. I believe that if we are talking about viable funding models, funding needs to address both feature and maintenance work and not tip the scale too far in one direction.

I'm not saying it's right, but a lot of people feel like open source means they are entitled to everything from getting binary releases, documentation, their bugs fixed on time, their feature requests implemented or their (sometimes deficient) PRs reviewed and accepted. All in need of careful communication which is easy to mess up.

A project that finances their development through getting paid for features will have to balance how much time they spend on paid vs. unpaid work. Getting maintenance work paid is hard.

I disagree on the sponsorship of issues being a good idea. Let's say there's an issue that's complex enough to warrant forking over several thousand dollars to cover the development cost. This will inevitably lead to a non-trivial amount of code being written. Who maintains that code in the future?

Any open source project adopting this model for funding will be in a perpetual cycle of chasing features and the rapid deterioration of code quality that comes with feature-driven development.

On the flip side, if a project opens an issue for "resolve security issue X" and refuses to ship a fix until it is paid for will be seen as holding the release hostage, resulting in a whole lot of negative press even though shipping a release can also be a serious amount of work.

I hold a very controvertial take on the dentist question: this and similar questions select candidates who can come up with convincing lines that lack any basis in facts (i.e. bullshit). This seems to be a good foundation for a terrible engineering/company culture.