Yeah… Ubuntu packages are never up to date on release date. They freeze them months before so they can iron out any bugs with the versions they picked. You don’t pick Ubuntu or any point release distro to get up to date packages.

If you can drop a .env file on a server. You can drop a well formed .ini file instead. I don’t see any reason to ever parse a env file as a ini file.

Debian has two main versions, stable - which is released every two years and supported for a long time. And unstable which is basically a rolling release and constantly changes adopting things to test them before the next stable release. There is also testing, but that is just to place thing in before promoting them to stable so has the same release cadence as stable.

Two years of fixed versions on a desktop is a very long time to be stuck on some packages - epically ones you use regularly. Most people want to use things that are newer then that, either new applications released or new features for apps they use in the past two years.

Ubuntu also has two release versions (that not really the right term though). They have a LTS version which is released every two years much like Debian is. But they also have a interim release that is released every 6 months. This gives users access to a lot newer versions of software and stuff that has been released more recently. Note that the LTS versions are just the same as the interim versions, its just that LTS versions are supported for a longer period of time, so you can use it for longer.

For the Ubuntu releases they basically take a snapshot of the Debian unstable version, and from that point on they maintain their own security patches for the versions they picked. They can share some of this work with Debians patches and backports, but since Debian stable and Ubuntu are based off different versions Ubuntu still needs to do a lot of work with figuring out which ones they need to apply to their stuff as well as ensuring things work on the versions they picked. Both distros do a lot of work in this regard and do work with each other where it makes sense.

Ubuntu also adds a few things on top of Debian. Some extra packages, does a few things that make the disto a bit more user friendly etc.

Any other distro that wants to base off one of these has to make the choice

• Do they want a very slow release cadence matching Debian (or Ubuntu LTS).
• Or do they want a faster release cadence of Ubuntu without doing much extra work as they can build off the work that Ubuntu is doing on top of Debian.
• Or do they want to take on all that extra work themselves and have more control over the versions included in their repos.

For a lot of distro maintainers basing off Ubuntu gives them a newer set of packages to work with while doing a lot less work doing all that work themselves. Then they can focus on the value adds they want to add ontop of the distro rather then redoing the work Ubuntu already does or sticking with much older versions.

The value add work that needs to be done on either base I dont think is hugely different. You can take the core packages you want and change a few settings, or remake a few meta packages that you dont want from Ubuntu. This is really all stuff you will be doing which ever one you pick. It is a lot more work keeping up with security patching everything.

You are not considered to be working somewhere until you have signed a contract and after the start date on that contract. Accepting a offer is not signing a contract. You are not working at the new place yet. You have no obligations to do anything at that point. You just need to have stopped working at your current employment before your start date. You definitely do not need to quit before accepting the offer. No where I have worked requires that.

You are right. You cannot onboard a new job before you leave your old one. Accepting an offer is not part of the onboarding process though. It happens before.

After an interview process the company makes an offer. The candidate can then accept or reject it. But that is really all informal. You can then negotiate with them for an official start date and contract. You just need to ensure you can hand in your notice and work the rest of your notice period before the start date of your new contract.

I don’t know anyone that would hand in their notice before accepting the initial offer of a company. At least here in the UK.

You assume they don’t already have a job and we’re just looking for other opportunities. Not everyone is unemployed before they apply for other jobs. If anything that is a good time to look as it gives you stronger position to negotiate from.

Yes it is a security issue. But almost everything is. You can make it secure enough with the right policies. However it overall increases the attack surface of your application and has a greater chance that you missed something or miss configured the policies. So many firebase apps have been hacked because of miss configured access to the database.

So it puts more work on you to get things right.

I treat warning as todos. Fix them all before I release something. I would only ever disable one if I know for a fact the warning is a false positive.

I would question why you are seeing so many warnings you are not sure about? If you keep on top of them you really shouldn’t have that many. Marking them all as allowed with a Todo comment feels just like you are burying you head in the sand.

I would leave them all there to keep nudging you to investigate and remove them. Hiding them behind a Todo will just mean you will ignore them. And warnings are important, they very likely point to a problem, even if that is just the code could be simpler. It is rare they are true false positives.

Free speech for him, not for you.

You really don’t. And probably shouldn’t. Remember this is the findings of a pen testing company that was working with these password managers. They found some issues. Issues that are very hard to pull off - you need the password manager servers to be completely compromised. Which is not something that happens often if at all. Vastly more common is just data exfiltration which bitwarden is secure against. Additionally the issues have already been addressed, in bitwardens article linked in that one:

All issues have been addressed by Bitwarden. Seven of which have been resolved or are in active remediation by the Bitwarden team. The remaining three issues have been accepted as intentional design decisions necessary for product functionality.

So you are already safer then before without having to do anything. Switching now all you are doing is switching to a provider that has not undergone this testing and may or may not have similar issues.

Don’t just jump at the first mention of things like this. You really need to look at the companies response - like Lastpasses who have given a token statement that basically says they are not going to fix these issues any time soon if at all. Stay away from companies like that. But companies like Bitwarden that actively fix issues that are found are worth sticking with.

The companies responses are probably more important then the findings.

Dashlane published a comprehensive response, thanking the researchers, and said the infoseccers’ decision to test using a malicious server model represented “a useful exercise.”

The vendor also confirmed it had fixed the most serious issue

Which is what you want to hear. The worst of the issues has been fixed and they look like they want to improve things further.

Bitwarden, meanwhile, said in a post: “Bitwarden has never been breached and believes third-party security assessments like these are critical to continue providing state of the art security to individuals and organizations.”

Is less encouraging although not damning. Would be nicer to hear they are hardening things in case of a breach rather than just relying on not being breached. They could still be doing that though.

A LastPass spokesperson told The Reg: “Our Security team is grateful for the opportunity to engage with ETH Zurich and benefit from their research. While our own assessment of these risks may not fully align with the severity ratings assigned by the ETH Zurich team, we take all reported security findings seriously. We have already implemented multiple near‑term hardening measures while also establishing plans to remediate or reinforce the relevant components of our service on a timeline commensurate with the assessed risk.”

Is just terrible. Basically they don’t think they have a problem and have done nothing more then a token effort to fix the easiest of things. I believe they have been breached before as well which is also a bad sign. They just don’t seem to care about security at all. I would continue to recommend no one use last pass and everyone one switch away from it.

I don’t fully believe this is purely an AI agent. Not after the moltbot incident raised how many humans where responsible for the posts on it. It just seems to be an attempt to make LLMs seems more autonomous then they actually are. It may have been written by an LLM, but I bet it was directed by a human trying to stir up drama.

You have picked some weird hills to die on there.

for x in list:

This is fine. Many languages now do it. The extra brackets around a for or if dont really add any clarity or make things easier or harder to read. This is the type of thing you just get used to and prefer what you are used to. You get over it quickly.

Why would you provide a way to type parameters but don’t enforce it at runtime?

This is a bit stupid, but really is legacy reasons for it. Since it didnt use to have static type declarations and wants to remain somewhat backwards compatible it needs to ignore them at runtime. But as a JS and PHP developer you should be used to this. Both do the same thing as python here with types (well, TS for JS and the many other attempts at getting types into JS). So it is weird that you are singling out python for this behavior.

Why so many different ways to declare an array-like structure? Tuples, Sets, Dicts, Lists?

DIcts are not array like here. Tuples sets and lists are all common is many languages as well. PHP is a real weird case here given everything, even arrays are effectively a dict - that is a strange language design feature. But Java is way worst for different types of array types in the language.

I’m mainly using it because of interoperability, easy to setup, i

What? I hate setting up python projects. Each one wants to use a different dependency or version manager. Yeah you might have python on most systems but they are all different versions and python is famously terrible at backwards compatibility. It seems every few versions they throw something in the breaks some existing scripts so you really need a version manager for things. Which is more complex setup and management of things. There are far too many different tools to help you with this and fetching dependencies which means if you work on lots of different projects by different people you have a hodge podge of diffing tools you need. It is a complete mess.

Personally I hate python as a language, but you have picked some minor points that IMO dont really matter or that the other languages you use also suffer from. There are far better things to pick from that are far more annoying in the language.

You cannot do that analysis with one sample. Why pick one day? That is an arbatary amount? Pick the 1 hour or minute that the CVE was released and you will find rust might be responsible for 100% of CVEs, Take a Week or year and that number drops dramatically. Pick the next day and that drops to 0%. You can select any % you want if you change what time period you are looking at.

The fact that there has been one cve in 5 years of rust in the kernel is a bigger tell. There will be more rust CVEs, and each one is going to be big news as they happen so rarely.

Email support was the bain of my existence. I forgot how many misconfigured system I came across decades ago that would fill up their filesystem with logs from crons in the root mail dir. Such a stupid default setting. We have vastly better methods for monitoring systems these days then firing off an email when a cron runs.

You can also easily see when the job last ran, if it was successful and when it will next run. As well as just trigger the service if you want it to run now.

I find most people don’t create good unit tests. They create them too small which results in them being fragile to change or near useless. They end up being a tray for future you not a love letter.

The number of times I have refactored some code and broken a whole bunch of unit tests is unreal. These types of tests are less then useless. If you cannot refactor code then what is the point in a unit test? I don’t need to know that if I don’t change the code under test it doesn’t break… I need to know that when I change code my assumptions still hold true.

We should be testing modules as a whole using their external API (that is external to the module, not necessarily the project as a whole), not individual functions. Most people seem to call these integration tests though…

Why wrap it in a function at all? Why not just put the if at the top of the file?

While true and some will do it for that reason, I bet most do it simply because the friction to forking is so low.

Some might have an intention to work on it but then don’t or might start looking at it in detail then give up or get to busy or lose interest.

Others might just click it to save it for later.

And don’t forget all the people that click it by accident.

It’s not like it is a big investment to click the button.

Probably something to do with their main package deleting the pacman lock file so it can run a nested pacman update command… Which means two pacman instances running at the same time and nothing stopping other ones after that nested one has completed.