lapser

Proton-bridge is a premium product you only get by being a paid subscriber. If it is open source, they should not be expecting contributions. One pays to make sure issues like this can be fixed, they don't pay to fix the issue themselves.

And yet, you'll still get sponsor segues.

I don't know if I'd call usage of a packet sniffer "easy to debug". Seems like it's reasonable to expect some debug option that is easy to activate in dev environments that will give you the relevant information.

How is this related? This was a) 10 years ago, b) nothing to do with injecting it in a cli, and c) in this instance Canonical is advertising their own product, within their own product, compared to the original where Amazon paid Canonical to advertise for them.

I believe this course (or something close to it) was taught in the University of Kent when I was there between 2009 and 2013. Really got my Linux game up to the point where I could switch to it fulltime.

Wikipedia has a list[0]. Obviously this doesn't include the unknown ones.

[0] https://en.m.wikipedia.org/wiki/PlayStation_3_cluster

Depending on your SSO provider, you can list all the roles using saml2aws[0] and then parse the output so you can generate the relavant config. It is a bit tedious, but it works.

[0] https://github.com/Versent/saml2aws/

I think USAF and other companies were likely part of the reason Sony removed Linux support. Generally, a PS3 was a lot cheaper than the equivalent PC/server.

Sony typically sells consoles at a loss and makes profits from the game sales. The likes of USAF, researchers, and other companies were buying PS3s in bulk, and using OtherOS functionality without utilizing the primary use of PS3s: games. Often these projects didn't need any GPU power, and OtherOS had nearly full access to the CPU (iirc it had access to the main PPE and 7 out of 8 SPEs). Thus, Sony likely was not making enough money from the consoles USAF et al. bought.

I've wanted to do it. Mostly to test out stuff that my colleagues would need to run but haven't been able because I run Linux. So I usually have to ask colleagues to double check my work.

I am aware that running macOS on non-Apple hardwade would be against their ToS.

You can just use Vagrant for this kind of setup. The benefit of that is you can provision so it is able to run your application and you're able to commit it to git and share it with others. Pretty sure it will have a qemu adapter too if you so choose.

Just install uBlock Origin. It blocks ads everywhere, not just YT.

Besides what the sibling comments said, it's very unlikely to that any script needs keys to the kingdom. Credentials should be created with limited access, just enough for the script to do its thing.

There is also Greenfoot[0], created by the authors of BlueJ, that focuses on building 2 dimensional simulations and games. I think Greenfoot is derived from the same source as BlueJ.

[0] https://www.greenfoot.org/

> I believe faculty at Kent (UK) had some kind of hand in building it too.

That's correct! Michael Kölling, one of the original authors, was a lecturer who wrote it originally. All of OOP classes were taught with BlueJ, but we were allowed to other editors, though not many did.

Have we come full circle? Sounds like we have. Maybe next up is news groups.

edent isn't lying though[0]:

> 1. First of all, love the Lord God with your whole heart, your whole soul, and your whole strength.

> 2. Then, love your neighbor as yourself.

> ...

> 72. Never despair of God's mercy.

[0] https://sqlite.org/codeofethics.html

I'm struggling to understand why this is useful. How is this useful from doing a docker exec, or kubectl exec?

Previous discussion: https://news.ycombinator.com/item?id=15971443

I'm surprised Oxford University is unable to handle the load from HN. Someone already posted the archive.is link.

I've been using delta for a long while, but this is the first time I've heard of difftastic. Why wouldn't you want the context all the time?

For folks on AWS I highly recommend investing in SSH over SSM in combination with EC2 Instance Connect. You can generate temporary ssh keys, send it to EC2 Instance Connect, it'll be on the server for 60 seconds. Then you can use ssm start-session to connect to the server over SSM. This also allows you to disable SSH ingress, and doesn't need a bastion or VPN.

This wouldn't matter anyway because the server can just give you access regardless of the auth provided.

Right, and the issue with that is that plenty of people lie, and even more exxagerate what they did.

I have checked it out. Also checked out Scalr and some other one that I can't remember the name of. Issue isn't finding an alternative, it's convincing the team to move away from TFE and TFC.

Because it sucks. It has all the quirks and a whole lot of mess. That's terraform. Terraform Enterprise and Cloud must have been developed as a fuck you to enterprises, because it absolutely sucks.

I work with them daily, and have done so for 4 years now. It still sucks.

Unfortunately it's (Terraform, not TFE/TFC) the best in its class, and quite frankly I'm not smart to solve its issues.

If you give every person on the street 2 hours of your time, you wouldn't be able to do your day job.

I don't like take home tests either, but the point of them is removing the bad candidates from the pipeline so that people who interview them (often ICs, and these are some of the biggest expenses within the company) don't waste time on someone that is unlikely to be qualified.

Personally when I'm interviewing and I get take home tests I choose my battles. I only do them if I really want the job. If it is worth my time.

It's unfortunate, but take home tests are a necessary evil until something better comes along.

You're missing the point. The official docker containers can be configured secure or insecure. Same with in house built containers. Same with installing an application via apt/yum/pacman/what-have-you.

Not sure why this is relevant, but here goes: I was working on a greenfield project where containers were at the core of it. The amount of due dilligence that was happening was great. Containers were scanned. Configuration was sanity checked. Generally security standards were pretty high. Surprisingly there were very few security folks who didn't know what they were talking about. Contrary to other banks I've been at who don't run on containers.

Comparing that with a neobank that runs K8s, successfully might I add, who has outdated software, and only recently started investigating upgraded.

The same configuration issues you mention has nothing to do with containers, as doing an apt-get install often has the same issues. It has everything to do with people using tools they have little understanding of. I'm talking about mysql, and mongodb, not docker.

For what it's worth, JSON Objects are not guaranteed to be ordered. Maps in many different languages are implemented without an order.

I have actually fully replaced my jq installation with gojq (including an `ln -s gojq jq`) for a few years, and no script has broken so far. I'm super impressed by the jq compatibility.

If you are going down this route, do be careful with performance. I don't know which is more performant as I've never really had to work with large data sets, but I can't help but feel jq will be faster than gojq in such case. I have no benchmarks backing this up, but who knows, maybe someone will benchmark both.

One of my favourite features is the fact that error messages are actually legible, unlike jq.

Yeah! I saw the PR. Looking forward!