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.
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.
I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c
You never want build artifacts to be committed. You don’t want to have everyone working on your project to need to setup their own gitignore for every project. So it makes sense to have a common commited gitignore for files the project produces that should never be tracked by git.
I dislike when people put in editor files in the gitignore though. People should setup global ones for their local tooling.
Yes. They can. But they do not mix well with required checks. From githubs own documentation:
If a workflow is skipped due to path filtering, branch filtering or a commit message, then checks associated with that workflow will remain in a “Pending” state. A pull request that requires those checks to be successful will be blocked from merging.
If, however, a job within a workflow is skipped due to a conditional, it will report its status as “Success”. For more information, see Using conditions to control job execution.
So even with github actions you cannot mix a required check and path/branch or any filtering on a workflow as the jobs will hang forever and you will never be able to merge the branch in. You can do either or, but not both at once and for larger complex projects you tend to want to do both. But instead you need complex complex workflows or workflows that always start and instead do internal checks to detect if they need to actually run or not. And this is with github actions - it is worst for external CICD tooling.
If you have folderA and folderB each with their own set of tests. You don’t need folderAs tests to run with a change to folderB. Most CI/CD systems can do this easily enough with two different reports. But you cannot mark them both as required as they both wont always run. Instead you need a complicated fan out pipelines in your CICD system so you can only have one report back to GH or you need to always spawn a job for both folders and have the ones that dont need to run return successful. Neither of these is very good and becomes very complex when you are working with large monorepos.
It would be much better if the CICD system that knows which pipelines it needs to run for a given PR could tell GH about which tests are required for a particular PR and if you could configure GH to wait for that report from the CICD system. Or at the very least if the auto-merge was blocked for any failed checks and the manual merge button was only blocked on required checks.
One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.
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
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.