What is the point in an official upgrade if it is unsupported? Seems like a way to trick people into an upgrade so they can start nagging users to throw away their hardware and get a new computer.
So glad I don’t have to worry about this bullshit on my 11+ year old computer that is perfectly fine running Linux without any major issue or lack of support.
I have updated arch systems that had not been powered on for years before. It was fine. No issues what so ever. Arch is not some flaky distro that breaks if you look away for a minute. My main system has had had the same install for over 5 years now and I regularly forget to update it for months at a time. Again, no issues.
To the NZXT community. We’ve heard your concerns. We are aware of the recent claims made against us and are actively reviewing the situation. Rest assured, we are committed to addressing this thoroughly and will share an official statement soon.
Translation: Fuck! you caught us. We are currently in PR disaster recovery mode and trying to figure out how to spin this to not look like complete scum bags. Rest assured, we are committed to trying to find some escape goat to throw under the bus and minimizing the damage to our reputation.
there are no Rust jobs
Neither OP nor I claimed that. Only that it is hard to find a job in rust or that knowing rust will not help you get a job today (more so than any other language that is). I do also think that rust has a bright future - but as things stand today it can be hard to get a rust job (at least ones that are not just for cryptocurrencies/blockchain). And it could take 5 or more years for significant change in that area.
Which validates the authors point - it can be hard to find or get a job writing rust. Much more so than other languages. Even if there technically are jobs around, just knowing rust wont help that much in obtaining one.
But is Rust merely a new face on Ada?
They share some features. But what language does not share any features with any other language? Any new language these days will be heavily inspired by and take features from other languages while making changes to or pulling in features from other places to create a mix that is unique to that new language. Rust is far more than just its GCless memory safety features and I am not even sure if they are inspired by ada or were just arrived at a similar solution to ada - they are not exactly a one to one matching with how ada does anything. If anything I believe that rust is much more heavily inspired by ocaml than ada.
The OP does have a fair point. Rust jobs are harder to find and generally require niche knowledge in some area more then rust knowledge.
But it applies to features, not coding practices
I disagree. It applies to everything. I would argue it applies to SOLID most of all. I do not find SOLID principals to be good ones to follow most of the time. Situational they can be useful but I have seen so many projects that strictly follow SOLID that becomes an unmaintainable mess.
If you struggle to understand the SOLID principles or think they are too general, then I would suggest you follow my SOLID Training Wheels until you understand them better.
I hate this excuse. If the answer to the problem is you are just not doing it right then it is a terrible answer. But lets look at some of this advice:
Summary: 1 piece of code has 1 responsibility. The inverse: 1 responsibility of code has 1 piece of code
Training Wheels:
Follow the 10/100 Principle
Do not write methods over 10 lines
Do not write classes over 100 lines
No. Just no. Making everything as small as possible is exactly what is wrong with the single responsibility principal. I agree that everything should have one responsibility, but that responsibility might be complex and require a lot of code. Hiding the code behind other functions does not make it easier to read, only means you need to jump around a lot in order to understand what it is doing which IMO makes things harder to read. Every time I jump location it gets harder to remember where you came from or what the wider context is. Keeping related code together is more important then creating small function.
Just take a look at the stdlib of almost any mainstream language. Like the ArrayList in Java, or Vec in rust. These classes are thousands of lines long with many methods being 10-20 lines of code with some even longer then that. Is this code bad or hard to read? Not for what it is doing. And code like this is not atypical in stdlibs, you can jump to almost any class/struct in a language of your choice and see similarly structured code. And in all cases the classes represent one thing and its methods do one thing on that object regardless of how many lines of code they contain.
If you have to change a class that already breaks the 10/100 Principle:
take your code out of that class and put it in a new class first so the original class is smaller
Check-in this refactor without your new code
make your changes in the new class
Check-in your new code
IMO this breaks the single responsibility rule. If new code is mostly related to a single class then it should be added to that class as that is what the class is responsible for. Adding a new class for every bit of logic just splits up the responsibility and makes it far harder to find what is responsible for something.
I could go on about the rest of that training guide - which this whole post seems to be an advert for.
YAGNI, will ruin your code base if you apply it to how you code.
It applies just as much to how you code as to what you are coding. If you added every programming paradigm and principal to your code base it would be a unreadable mess. Not to mention impossible to do as loads of these conflict with each other.
Pick the right tools for the right job. Don’t blindly apply anything to every situation. There are times when the SOLID principals can help but there are also times where they make code worst. Instead always ask yourself if there is a simpler way you could be doing something and if when applying a principal if it actually made the code easier to read (ask someone else as well as it can be hard to tell yourself). Don’t be afraid to break a principal if it is not helping.
It’s a zero cost bool!
It really is not. Dynamic dispatch has a cost on every access due to it being a pointer. Instead if doing a bool check you are needing to read a pointer to figure out which function to call. I doubt this is any faster than just having the bool check and I doubt that the bool check is slowing anything down by a noticeable amount. All of this is probably not worth the complexity, especially without benchmark results as I can see this actually slowing down the code overall.
There is also a increased binary size due to there needing to be two versions of the code block - if you have that in every function that would be a dramatic increase in the binary size. This means more data needs to be loaded into memory at startup and I don’t know if the branch prediction in your CPU worth with vtables?
Maybe if you already need dynamic dispatch for something it might be worth it. But most of the time I would avoid it if possible which means this pattern has a very limited usecase that you cannot use over the whole program? What is wrong with the standard logging crates in rust? I would expect them to be good enough even for game dev.
Don’t have a knee-jerk reaction to every news post that you see. We have yet to see what will happen and you will have loads of time to decide on what to do when we do know if it will get pulled. You will be able to use your current kernel version with it for as long as you need to even if it does get pulled from the next version. So I would wait and see what actually happens.
Best option is likely a reinstall of your OS to move off it though there are other more involved ways like copying your rootfs off, reformatting and copying it back before reinstalling your bootloader. A reinstall is likely going to be quicker though.
You don’t need to worry about that in rust. Cargo is built from the ground up to understand package versions and downloads/builds the right versions for each project. The global package caches understand versions and can cache multiple versions of each package. Where as python just uses one or more global stores of packages shared by all projects. venv is basically there to isolated these package stores along with the version of python which can have breaking changes between different releases (this is something rust avoids at all costs so you can upgrade it without worrying as much as with python).
Not anymore because all the reason I mentioned. Has the experience change in recent years? Not likely. It is the same software as in other distros - just years out of date. That has not changed as the goals of these projects have not changed. They might be on newer versions then 10 years ago but they are still way behind more frequently updated distros - or at least will be very shortly. That is fundamentally how these enterprise distros work. Their target audience is businesses needing support, not lots of end users.
The big attraction towards these distros are the support that enterprise people will pay for - which you do not get with the free version. If you don’t mind older versions of things then it might be nice for you. If not then I would stay clear of them.
Older software is the most noticeable thing. Enterprise does not mean it is better - just that it is supported for a long time and they do that by not changing much on them. They are more designed for servers rather than workstations and generally not a great experiences unless you are running hundreds or thousands of them in an enterprise situation.
Professional just means payed for. What you are paying for is support in managing the systems, not a great user experience.
For home desktops it is far nicer to be on newer software rather than things that came out 5 to 10 years ago.
If that were the main goal why not just ban them from the extension store? Or why allow manifest v3 extensions to block requests at all? Ad blockers still work and this did not kill off any of them. Just forced them to change some of their functions. I don’t doubt the executive overlords are happy about the turmoil that this has done to ad blockers but they would be pissed if that was the only or main goal of this as there are still loads of effective adblockers about.
That is a more complex story then that. The manifest v3 changes primary give a lot of security and privacy changes that stop extensions from doing a lot of questionable things in the background on all your page you visit. But that does stop ad blockers from doing a lot of what they currently do - blocking in page elements and modifying the pages you visit. But it does not block them from blocking page requests so ad blockers like ublockorigin lite can still function in a more limited capacity to block ads.
I do think the teams outside of the chrome team are happy for this change - but I don’t think the chrome team set out to do this purely or even mainly to block ads.
Besides even if they did it does not change my argument - whom ever buys chrome will likely want to squeeze it for more money then google currently are doing and will likely do far worst things like including ads directly in the browser. Or trying to monetize it in some other way.
I would love it if chrome where maintained by some non-profit foundation. But how likely is that going to be from a court order sell off?
I would rather they split up google in other ways first.
TBH I am not sure this will end well at all. Google needs to e broken up but splitting off chrome? What will that achieve? Chrome does not directly make any money for Google really, they don’t sell it, they don’t sell ads in it, they don’t even collect much personal data though it. No where near as much as they really could if they really wanted to. Google have not been terrible at managing chrome or pushing as much profit out of it as they could.
Instead they are using it to create a good platform for all the rest of their services where they actually make money. So what will selling off this loss leader do for chrome? Most likely it will get bought up by someone else that will want to see a return on investment that wont be using it as a loss leader. Which I can very well see it getting en-shitified like everything else that is purely driven by profit.
Best case it is gets bought by a non profit foundation that can develop and take care of it - but lets be real, they wont have the money to out compete anyone wanting to buy it to make more money.
I personally don’t really trust google with my browser either - hence why I avoid chrome. But I would trust anyone seeking to buy it for profit far less and can very well see this as a overall negative if the wrong people buy it (which I see as more likely).
That being said, I don’t keep one in my car.
Now is the time to change that.
Um no. Containers are not just chroot. Chroot is a way to isolate or namespace the filesystem giving the process run inside access only to those files. Containers do this. But they also isolate the process id, network, and various other system resources.
Additionally with runtimes like docker they bring in vastly better tooling around this. Making them much easier to work with. They are like chroot on steroids, not simply marketing fluff.
Documentation is generally considered one of the stronger points of rust libraries. Crates.io is not a documentation site you want https://docs.rs/ for that though it is generally linked to on crates.io. A lot of bigger crates also have their own online books for more in depth stuff. It is not that common to find a larger crate with bad documentation.
The article calls that out explicitly:
What is the point in upgrading if you wont get security upgrades either way. Just more spyware and ads in the newer version.